Skip to content

Create Node-Target-Mapping.md #182

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jun 19, 2019
Merged

Create Node-Target-Mapping.md #182

merged 1 commit into from
Jun 19, 2019

Conversation

orta
Copy link
Contributor

@orta orta commented Aug 11, 2018

This is the bare minimum to get some docs started for the node lib/target mapping.

Related:

@orta
Copy link
Contributor Author

orta commented Jun 19, 2019

Oh, hey, it's my own PR - nice.

Yeah, this is still worth having IMO

@orta orta merged commit ff67c74 into microsoft:master Jun 19, 2019
@styfle
Copy link
Contributor

styfle commented Jun 19, 2019

@orta It might also be a good idea to also mention esnext here to avoid all downlevel-helpers.

I often use esnext with Node but I'll use es2017 for browsers.

@SimenB
Copy link

SimenB commented Jun 20, 2019

Include node 12 as well?

@BrendanBall
Copy link

Seems like this is something that should be automated with a script? There are way too many individual flags to check

@orta
Copy link
Contributor Author

orta commented Sep 10, 2019

Honestly, there's a good argument for having these as options inside TypeScript itself (though it looks like that failed to stick) but I don't think this is just scriptable TBH there's not really two tables of definitions for features in node vs in TS. Just gotta do the grunt work to make sure they're in line for the docs.

@styfle
Copy link
Contributor

styfle commented Sep 10, 2019

One thing that might be difficult to get right is that Node 10 might get a new feature in Node 10.5 for example so settings target=node10 would be a moving target.

Although, there is precedent for such a flag: strict which could break an app upon updating TS when a new strict feature is introduced.

The problem is that you don't know if the user wants to target Node 10.1 or 10.5 and this would break at runtime which is much worse than strict which breaks at compile time.

Documenting is a good first step, but to add these settings into tsc will take some careful thought.

@SimenB
Copy link

SimenB commented Sep 10, 2019

Just doing whatever babel-preset-env does when people define {targets: {node: 10}} makes sense, no? Which means a moving target, but if the user don't wanna be specific, that's on the user. And precedence in babel makes it pretty ok in my mind 🙂

@AndrewKvalheim
Copy link

Link to the live page for convenience:

@Urigo
Copy link

Urigo commented Feb 19, 2020

If anyone wants to try the latest, not LTS version, on my personal apps I've been using latest Node (13.8.0) with native ES modules and with target es2020 and it's been working great so far.
Here is a simple example

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants