Rename module resolution option node to node10 (preserving backward-compatible alias)
#51901
Conversation
typescript-bot
added
Author: Team
For Uncommitted Bug
|
Likely after the holidays, I also want to discuss a process for transitioning various defaults away from |
| classic: ModuleResolutionKind.Classic, | ||
| node16: ModuleResolutionKind.Node16, | ||
| nodenext: ModuleResolutionKind.NodeNext, | ||
| bundler: ModuleResolutionKind.Bundler, | ||
| })), | ||
| deprecatedKeys: new Set(["node"]), |
There was a problem hiding this comment.
Right now, this only filters the config parsing diagnostic that says what the valid options are (next changed lines in this file).
|
Somehow I failed to update a big batch of baselines with this kind of change - "Module resolution kind is not specified, using 'NodeJs'.",
+ "Module resolution kind is not specified, using 'Node10'.", |
| @@ -3391,7 +3391,7 @@ | |||
| "category": "Error", | |||
| "code": 2791 | |||
| }, | |||
| "Cannot find module '{0}'. Did you mean to set the 'moduleResolution' option to 'node', or to add aliases to the 'paths' option?": { | |||
| "Cannot find module '{0}'. Did you mean to set the 'moduleResolution' option to 'nodenext', or to add aliases to the 'paths' option?": { | |||
There was a problem hiding this comment.
I also meant to leave some commentary on this change. This message was written when there were only two module resolution options, and only one worked with non-relative specifiers. Now that there’s node16, nodenext, and bundler, it’s a bit harder to infer what someone on classic should be on instead. I picked nodenext, but we could revisit this message in the future if we need to.
- microsoft/TypeScript#51901 Signed-off-by: Lexus Drumgold <unicornware@flexdevelopment.llc>
Part of #50152
This does not make it an error to specify
--moduleResolution node, but does ensure that if we ever mention the option, we call itnode10. I’m going to see if we can give another push away fromnodewhen editing tsconfig files in VS Code as well. (I had initially proposed removingnodefrom the JSON schema, but ideally we would want to do that only if the user’s TypeScript version is 5.0+, at least until that’s widely adopted.) That’s probably the extent of the deprecation warnings/errors we’ll be able to give.