Target compiler flag should allow me to choose a Node.js version

[JustinBeckwith]

Greetings folks! Little feature request. Today when I specify the compilation target, I choose an es level (2015, 2016, 2017, Next, etc). I primarily use TypeScript for Node.js apps, and what I'd really love is a way to target specific releases of node.js. Something like:

"target":  "node8"

This would take a lot of the guesswork out if I know my min-nodejs version, and I don't care about targeting the browser.

[ofrobots]

+1. Note that language levels don't precisely map to Node (or even browser) versions at all times. Node 6 has most everything, but not all, of ES2015. Node 7 and 8 have async-await but not all the rest of ES2017.

As a Node.js library developer I want to make sure that the code I am shipping matches the minimum Node.js version that I support. Any extra polyfills add debugging, cognitive and performance overhead.

Note that this issue isn't asking to allow users to pick and chose which language features to enable (which has been discussed in the past on this issue tracker). It is asking for target to support implementation levels rather the specification levels. The former is what people can actually target.

[RyanCavanaugh]

People have also asked for this for browser runtimes. We really don't have the resources to keep active tabs on every JS runtime's per-version progress. It's generally not problematic to over-downlevel syntactic features and non-syntactic features can be safely polyfilled through other means.

[ofrobots]

@RyanCavanaugh Node semver major versions are released twice a year, so I think the resource requirement would be quite low.

If that is still too much work, would you entertain external contribution and ownership of such a table for Node.js?

[RyanCavanaugh]

If you want to have a wiki page for "Recommended target and lib settings by Node version", sure, send a PR 👍

[ofrobots]

That wouldn't solve the problem at hand. Recommended target version for Node 8 would be ES6 which means that we don't get native async-await support. Debugging poly-filled async-await doesn't have the same user experience as native. So while it is not problematic functionally, it is problematic from a user experience point of view.

Your original push-back was lack of resources to maintain the table. I've offered to help maintain the table. Could you elaborate on where the remainder of your push back is coming from?

[DanielRosenwasser]

Your original push-back was lack of resources to maintain the table. I've offered to help maintain the table. Could you elaborate on where the remainder of your push back is coming from?

Hey @ofrobots, that is generous of you, and we appreciate the offer, but that work still needs to be overseen and verified by the team, and is still a non-zero cost on our side.

Additionally, the work here unfortunately isn't a matter of "just figure out which transforms to disable/enable" because our transforms typically downlevel an entire version of ECMAScript at a time (barring generators and module systems). This helps us not just by affording some flexibility in our implementation, but also helps speed certain things up (fewer individual passes). So there's also the current level of granularity we're willing explore within our emit pipeline.

[ofrobots]

@DanielRosenwasser Thanks for explaining. I guess the longer feedback in that case would be to consider that you're making a trade-off between 'flexibility of implementation' and 'out of the box user experience', specially for Node.js users. It is a fine to make the choice you're making, but it is important to recognize the trade-off.

[typescript-bot]

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.