Target NodeJS version

[eugene1g]

Is there a list of which NodeJS versions you are targeting with this library?

Currently, tsconfig target is ES5 as per

conveyor-mq/tsconfig.json

Line 3 in 07459ad

"target": "es5",

This will compile all goodness like async function down to using generators, which is probably not desired for a modern library. For a server-side lib, you could use es2018 which would keep native async functions, spread operators, etc and Node v10 is 100% compatible with that setting.

[jasrusable]

Hey @eugene1g, thanks for the heads up about this. I'll look into the different targets and see what the options & tradeoffs are :)

[glensc]

I wonder is there good table that says which target maps to which node version.

I found answer to that once in stackoverflow, but unable to find anymore.

[eugene1g]

@glensc This might be close https://node.green - rows are for "ESxxxx" features, and columns are for NodeJS versions. For example, target: "es2018" is expected to work on Node10+ which is the current oldest LTS.

[glensc]

@eugene1g that's very difficult to read. I'm looking for a simple table that summarizes:

target	node version
es2018	node10+

[eugene1g]

@glensc Those declarations would be misleading because compatibility is not binary. ES releases include many features, but each JS engine/vendor chooses what to implement independently - so we get endless permutations of "90% works in vX, but that one thing doesn't".

For example, Array.prototype.values is part of ES2015, but by some miracle not supported by Node until v10.18. However, it would be misleading to state that Node 10 is not compatible with ES2015 because basically nearly no-one used this feature from the standard.

It's up to each developer to assess if they use any uncommon features, and declare compatibility based on that. The developer would lean towards being helpful rather than being precise. If you use async functions standardized in ES2017, well they work perfectly in Node since 7.6. But "technically"Atomics.wake was also part of ES2017, and they aren't supported even in Node14, so "technically" Node14 is not compatible with ES2017. But you wouldn't want to compile your promises down ES5 and punish performance because the same standard defines an esoteric feature nobody uses.

[glensc]

Thanks for the huge rant. It can be perhaps still simplified given what typescript generator supports and uses, i.e the directive in question is in tsconfig.json.

[jasrusable]

@eugene1g Do you have any idea what the runtime performance of the different targets (in tsconfig.json) are and how them compare? What has the better runtime performance between a target of es5 vs es2018 for example?

On this topic, I have come across http://incaseofstairs.com/six-speed/ which seems to break down the runtime performance of es5 vs es6 across various different platforms quite nicely.

[eugene1g]

The case for updating target to e.g. ES2017 is not so much about performance as it is about using the platform. Node natively can run async functions natively, but with target=ES5 TypeScript will change this source code

const sayHi = async ({ name = 'Bob'}) => `Hi ${name}`;

into this JS code

With target=ES2017, the same input becomes:

(see TS playground)

This code is recognizable, debug-able by the final user/developer, and runs on Node8+ which has EOL'ed and not officially supported in most places.

target=es5 is appropriate for a frontend library that needs to work in IE11 because it doesn't support anything better. However, IE11 limits should not define the standard for a server-side library. V8 is rapidly improving with better features, tools, performance, etc, and as developers we can benefit immensely by using the platform's native features rather than betting against them.