-
Notifications
You must be signed in to change notification settings - Fork 237
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
Update module and moduleResolution to stop using node and invalid combintations #197
Conversation
@@ -8,7 +8,8 @@ | |||
"esModuleInterop": true, | |||
"jsx": "react", | |||
"lib": ["DOM"], | |||
"moduleResolution": "Node16", | |||
"module": "esnext", | |||
"moduleResolution": "bundler", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Related: #196 and facebook/docusaurus#9050 (comment)
@@ -4,6 +4,7 @@ | |||
|
|||
"compilerOptions": { | |||
"module": "es2022", | |||
"moduleResolution": "bundler", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I strongly object to this base existing at all. It’s a trap that might prevent a user from finding the config they should be using for Node or Vite or whatever.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I delisted it in the latest commit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the suggested approach to now use base/node18 and then set moduleResolution manually in tsconfig.json to bundler?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would like to know that as well. It's not clear to me what is the recommended config for ESM modules which target nodejs (particularly 22). What if it's modules shared between frontend and backend in a monorepo?
"target": "es2019", | ||
|
||
"strict": true, | ||
"esModuleInterop": true, | ||
"skipLibCheck": true, | ||
"forceConsistentCasingInFileNames": true, | ||
"moduleResolution": "node" | ||
"moduleResolution": "node16" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes reflected in node16
are mostly present as of Node v12.
This all makes sense to me!
|
Yeah, it’s pretty new (5.0). I noticed some |
I'll do it, and I'll ping a few folks who should at least see this coming through:
I'll give it a few days before a merge, and I've sent you an invite to be a collab too |
Svelte change looks good to me 👍 |
@@ -11,7 +11,7 @@ | |||
"noEmit": true, | |||
"esModuleInterop": true, | |||
"module": "esnext", | |||
"moduleResolution": "node", | |||
"moduleResolution": "bundler", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would be a breaking change in Next.js since its only TS 5+
While we're at it, we could probably remove target
since Next.js doesn't use it.
Also include
looks outdated since its missing ".next/types/**/*.ts"
You can find the latest with create next app
@@ -11,6 +11,6 @@ | |||
"esModuleInterop": true, | |||
"skipLibCheck": true, | |||
"forceConsistentCasingInFileNames": true, | |||
"moduleResolution": "node" | |||
"moduleResolution": "node16" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be nodenext
instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, it should match the module setting above (the linked PR on TS would enforce it). At the moment, node16 is nodenext, as no new resolution semantics have been introduced. Eventually maybe there will be a node24 if that version changes something.
Related, but "node" was renamed to "node10" for that reason.
bases/ember.json
Outdated
@@ -2,15 +2,15 @@ | |||
"$schema": "https://json.schemastore.org/tsconfig", | |||
"display": "Ember", | |||
"docs": "https://docs.ember-cli-typescript.com", | |||
"_version": "2.0.0", | |||
"_version": "2.1.0", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As suggested on the main discussion, it would be helpful for us to treat this as 3.0.0 if it’s explicitly bumping the minimum TS version. However, I have not fully taken on the overall approach here. If (per the README change) it is going going to be effectively bumped with every release, we may need to reevaluate the approach. Ember itself is also at a point where we could poeple finally look at just shipping an @ember/tsconfig
instead, inverting this and leaving Ember in control of those bumps. I will dig in further and chat with the rest of the team and follow up!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Happy with whatever works for you - could bump to 4.x because that matches the LTS of embed for example too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's just go with a clean major for now:
"_version": "2.1.0", | |
"_version": "3.0.0", |
Medium-term, I think we'll probably end up switching to an @ember/tsconfig.json
so we can manage our own versioning scheme with it (that makes good sense for how we're approaching Ember's own SerVer commitments re: TS support).
Cool, I think this is everything then 👍🏻 I've bumped the majors on all of the affected bases and noted why the esm build is deprecated |
Thanks all! |
For folks coming to this thread trying to figure to some of the types, I'd recommend looking at https://arethetypeswrong.github.io/ |
Ran into a ton of problems with this change. Typescript recommends using https://www.typescriptlang.org/docs/handbook/module-resolution.html#module-resolution-strategies
|
That page is many years out of date and will be deleted / completely rewritten soon. |
Per microsoft/TypeScript#54567 and microsoft/TypeScript#54735, I’m planning to make it an error to mix
node16
module/moduleResolution with non-matching values for the other field. I’m also taking this opportunity to replacenode
(which is for Node 10!) withbundler
where applicable.