Start Node ESM stable version at Node16 #48879

DanielRosenwasser · 2022-04-28T20:00:34Z

Today Node 16 provides two really nice characteristics:

It supports all the resolution modes of Node 12 and Node 14 (a difference which won't be fixed)
It supports ES2022 features, including top-level await, ??=, #private fields, numeric separators, error causes, and more. This is nice because even if you're not transforming your input code, you won't get an error for using some of these constructs.

This PR starts our minimum stable version of Node targeting and resolution to Node 16 instead of Node 12.

There is a caveat which @weswigham pointed out, which is that top-level await isn't yet documented as stable.

ghost · 2022-04-28T20:00:47Z

Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

❌ DanielRosenwasser sign now
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

DanielRosenwasser · 2022-04-28T20:08:34Z

src/compiler/checker.ts

@@ -33101,10 +33101,11 @@ namespace ts {
                                Diagnostics.await_expressions_are_only_allowed_at_the_top_level_of_a_file_when_that_file_is_a_module_but_this_file_has_no_imports_or_exports_Consider_adding_an_empty_export_to_make_this_file_a_module);
                            diagnostics.add(diagnostic);
                        }
-                        if ((moduleKind !== ModuleKind.ES2022 && moduleKind !== ModuleKind.ESNext && moduleKind !== ModuleKind.System && !(moduleKind === ModuleKind.NodeNext && getSourceFileOfNode(node).impliedNodeFormat === ModuleKind.ESNext)) || languageVersion < ScriptTarget.ES2017) {
+                        if ((moduleKind !== ModuleKind.ES2022 && moduleKind !== ModuleKind.ESNext && moduleKind !== ModuleKind.System && !(moduleKind >= ModuleKind.Node16 && getSourceFileOfNode(node).impliedNodeFormat === ModuleKind.ESNext)) || languageVersion < ScriptTarget.ES2017) {


Actually, this check is wrong and the tests reflect that. Should it be

Suggested change

if ((moduleKind !== ModuleKind.ES2022 && moduleKind !== ModuleKind.ESNext && moduleKind !== ModuleKind.System && !(moduleKind >= ModuleKind.Node16 && getSourceFileOfNode(node).impliedNodeFormat === ModuleKind.ESNext)) || languageVersion < ScriptTarget.ES2017) {

if ((moduleKind !== ModuleKind.ES2022 && moduleKind !== ModuleKind.ESNext && moduleKind !== ModuleKind.System && !(moduleKind < ModuleKind.Node16 && getSourceFileOfNode(node).impliedNodeFormat === ModuleKind.ESNext)) || languageVersion < ScriptTarget.ES2017) {

Normally we still emit warnings of some kind when using experimental features, which would still be in all stable versions of node, at least until nodejs/node#42875 ships in the next version of node 18.

So maybe until TLA becomes non-experimental we could issue an error like

Top-level 'await' is currently experimental in Node.js. It can only be enabled when the 'module' option is set to 'nodenext'.

On a related note, we should probably remove the experimental warning for json imports in nodenext. Afaik, they've stabilized in node 18. At least the version with the import assertion, anyway. It's contentious among the node maintainers.

The PR is already merged - that seems like a pretty strong sign that it will be stable, right?

The test wasn't wrong, it was just very confusing because the code was in a CJS file. I've updated the check there.

Yeah, it'll be stable in the next release of node 18, it just hasn't shipped yet, and I don't know if it'll be backported to 16 or not.

At what point do they stop backporting features like that? Maintenance LTS? Is it practical to not create a named moduleResolution target until it solidifies?

Changes are backported to LTS versions unless they're somehow breaking from what I understand, while maintenance LTS versions only get security patches. At least I think that's the general policy. (The definition of "breaking" being the somewhat subjective part)

src/compiler/checker.ts

… CJS files.

DanielRosenwasser · 2022-04-29T01:05:25Z

Newest updates give a better error message when you have TLA in a CJS module.

…ger experimental.

DanielRosenwasser · 2022-04-29T01:26:52Z

Most recent changes remove the error message for importing a JSON module under Node16 and NodeNext.

DanielRosenwasser · 2022-04-29T17:52:46Z

A decent amount of stuff seems to already use/support Node 12.

https://cs.github.com/?scopeName=All+repos&scope=&q=%22%5C%22module%5C%22%3A+%5C%22node12%5C%22%22+language%3A%22JSON+with+Comments%22

Should we keep it undocumented and provide an error when using it, but continue supporting it otherwise?

weswigham · 2022-04-30T02:04:22Z

I mean, as I said back in the issue, I'm all for having newer stable versions to match the node versions people wanna target, alongside the existing versions we support, in the same way we build out a new esXXXX target every year (potentially if only to match up that node version to the correct esXXXX target automatically). If we only do even-numbered (and thus LTS) node versions, we should only need to add one every year or so as well.

Sounds like we have fairly good reasons to have both node16 and node18, in addition to 12, since 16 has all those fun es2022 features and 18 has stablized tla and JSON imports, while 12 already has some use.

DanielRosenwasser · 2022-05-02T21:57:15Z

Spoke with @ahejlsberg and @andrewbranch on this. We could just say Node18 as the initial minimum target which would simplify a bit for us; however, like you've mentioned, Node 18 can get more and it's not yet the active LTS. So let's start with Node 16 and if we see anything that diverges, we can add a Node18 target down the line.

DanielRosenwasser · 2022-05-02T21:58:28Z

Consensus was on not providing a workaround for nightly-only users. Either you have nightly TS in a lockfile or you've signed yourself up to staying up-to-date.

weswigham · 2022-05-02T22:17:58Z

Just remember that any perceived simplicity from initially supporting fewer explicit node versions is very likely a short-lived pipe dream at best - we will have to add more, the same way we add esXXXX targets every year. The kind of big-bang module system update that happened with the esm transition is not how node usually does development, usually you get more minor changes each release, as we can already see between 12, 14, 16, and 18. (And the only reason we didn't see a need to update the commonjs resolver for so long is because all those minor resolver changes were being banked up for the node 12 esm drop - even the cjs ones.) If the issue is the perceived complexity or messaging of many targets, that can is only being kicked, not fundamentally solved.

IMO, a longer term more complete solution would be following in the footsteps of... pretty much every js transforming tool in the js community (eg, babel via preset-env, rollup's target argument), and taking arbitrary engine versions/ranges and mapping them automatically to our internal feature flags (eg, es target, module (resolution), and emit features). That would be more predictable into the future, imo. Messaging is probably simpler: 'specify all desired target runtimes, eg target: node18.1.1,chrome101,firefox102,... and we'll figure out the rest.' where you can even specify future versions we don't explicitly handle yet and we can assume those map to next variants of our various features until we add explicit mappings.

See microsoft/TypeScript#48879 for background

sheetalkamat · 2022-05-05T17:02:59Z

.../tsbuild/moduleSpecifiers/synthesized-module-specifiers-across-projects-resolve-correctly.js

@@ -134,296 +134,33 @@ Output::

 [[90m12:00:26 AM[0m] Building project '/src/src-types/tsconfig.json'...

-[[90m12:00:33 AM[0m] Project 'src/src-dogs/tsconfig.json' is out of date because output file 'src/src-dogs/dog.js' does not exist


Can you fix the tests to modify lib file so there are no errors are we are really testing the scenario.

Created #48974

sheetalkamat · 2022-05-05T17:03:16Z

...-in-output-declaration-file-from-referenced-project-correctly-with-cts-and-mts-extensions.js

@@ -16,7 +16,7 @@ export type TheNum = 42;
 export type { TheNum } from './const.cjs';

 //// [/user/username/projects/myproject/packages/pkg2/tsconfig.json]
-{"compilerOptions":{"composite":true,"outDir":"build","module":"node12"}}
+{"compilerOptions":{"composite":true,"outDir":"build","module":"node16"}}

 //// [/user/username/projects/myproject/packages/pkg2/package.json]


Same for this

Remove Node12, add Node16.

c0f2882

DanielRosenwasser requested review from weswigham, andrewbranch and ahejlsberg April 28, 2022 20:00

typescript-bot assigned DanielRosenwasser Apr 28, 2022

typescript-bot added Author: Team For Milestone Bug PRs that fix a bug with a specific milestone labels Apr 28, 2022

DanielRosenwasser commented Apr 28, 2022

View reviewed changes

src/compiler/checker.ts Outdated Show resolved Hide resolved

Accepted baselines.

52d1ea5

DanielRosenwasser force-pushed the toNode16 branch from bdf9922 to 52d1ea5 Compare April 28, 2022 20:28

DanielRosenwasser added 2 commits April 29, 2022 01:04

Refactor checking for top-level await, give a better error message in…

1247217

… CJS files.

Accepted baselines.

c390b79

DanielRosenwasser added 6 commits April 29, 2022 01:16

Stop erroring on JSON module imports in node ESM since they're no lon…

8b1e656

…ger experimental.

Accepted baselines.

ce98f0a

More refactoring, do the same checks for for-await loops.

fac5ded

Accepted baselines.

5305796

Adjust phrasing to permit for-await on CJS error.

1ca971d

Accepted baselines.

4c46f26

DanielRosenwasser mentioned this pull request Apr 29, 2022

[do not merge] Add node16 to jsconfig, swap from node12 to node16 in tsconfig. SchemaStore/schemastore#2216

Merged

DanielRosenwasser added 2 commits April 29, 2022 01:37

Accepted baselines.

830871c

Fix lints.

9d7fae8

DanielRosenwasser requested a review from jakebailey May 2, 2022 21:57

andrewbranch approved these changes May 3, 2022

View reviewed changes

DanielRosenwasser merged commit 5f9c9a6 into main May 3, 2022

DanielRosenwasser deleted the toNode16 branch May 3, 2022 23:29

chriskrycho added a commit to true-myth/true-myth that referenced this pull request May 5, 2022

Use 'Node16' to support TS 4.7

5c4d82f

See microsoft/TypeScript#48879 for background

chriskrycho mentioned this pull request May 5, 2022

Use 'Node16' to support TS 4.7 true-myth/true-myth#376

Merged

sheetalkamat reviewed May 5, 2022

View reviewed changes

sheetalkamat mentioned this pull request May 5, 2022

Fix node16 tests for module resolution #48974

Merged

balazsorban44 mentioned this pull request May 30, 2022

fix: always write moduleResolution to tsconfig.json vercel/next.js#37302

Closed

11 tasks

nickytonline mentioned this pull request Jun 28, 2022

feat: add support for in-memory cache netlify/hydrogen-platform#37

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Start Node ESM stable version at Node16 #48879

Start Node ESM stable version at Node16 #48879

DanielRosenwasser commented Apr 28, 2022

ghost commented Apr 28, 2022

DanielRosenwasser Apr 28, 2022

weswigham Apr 28, 2022

DanielRosenwasser Apr 28, 2022 •

edited

Loading

weswigham Apr 28, 2022

DanielRosenwasser Apr 29, 2022

DanielRosenwasser Apr 29, 2022

weswigham Apr 29, 2022

andrewbranch May 2, 2022

weswigham May 3, 2022 •

edited

Loading

DanielRosenwasser commented Apr 29, 2022

DanielRosenwasser commented Apr 29, 2022

DanielRosenwasser commented Apr 29, 2022

weswigham commented Apr 30, 2022 •

edited

Loading

DanielRosenwasser commented May 2, 2022

DanielRosenwasser commented May 2, 2022

weswigham commented May 2, 2022

sheetalkamat May 5, 2022

sheetalkamat May 5, 2022

sheetalkamat May 5, 2022

	if ((moduleKind !== ModuleKind.ES2022 && moduleKind !== ModuleKind.ESNext && moduleKind !== ModuleKind.System && !(moduleKind >= ModuleKind.Node16 && getSourceFileOfNode(node).impliedNodeFormat === ModuleKind.ESNext)) \|\| languageVersion < ScriptTarget.ES2017) {
	if ((moduleKind !== ModuleKind.ES2022 && moduleKind !== ModuleKind.ESNext && moduleKind !== ModuleKind.System && !(moduleKind < ModuleKind.Node16 && getSourceFileOfNode(node).impliedNodeFormat === ModuleKind.ESNext)) \|\| languageVersion < ScriptTarget.ES2017) {

		@@ -134,296 +134,33 @@ Output::

		[[90m12:00:26 AM[0m] Building project '/src/src-types/tsconfig.json'...

		[[90m12:00:33 AM[0m] Project 'src/src-dogs/tsconfig.json' is out of date because output file 'src/src-dogs/dog.js' does not exist

Start Node ESM stable version at Node16 #48879

Start Node ESM stable version at Node16 #48879

Conversation

DanielRosenwasser commented Apr 28, 2022

ghost commented Apr 28, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

DanielRosenwasser Apr 28, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

weswigham May 3, 2022 • edited Loading

Choose a reason for hiding this comment

DanielRosenwasser commented Apr 29, 2022

DanielRosenwasser commented Apr 29, 2022

DanielRosenwasser commented Apr 29, 2022

weswigham commented Apr 30, 2022 • edited Loading

DanielRosenwasser commented May 2, 2022

DanielRosenwasser commented May 2, 2022

weswigham commented May 2, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

DanielRosenwasser Apr 28, 2022 •

edited

Loading

weswigham May 3, 2022 •

edited

Loading

weswigham commented Apr 30, 2022 •

edited

Loading