Update module and moduleResolution to stop using node and invalid combintations by andrewbranch · Pull Request #197 · tsconfig/bases (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation21 Commits8 Checks0 Files changed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
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 replace node (which is for Node 10!) with bundler where applicable.
| @@ -8,7 +8,8 @@ |
|---|
| "esModuleInterop": true, |
| "jsx": "react", |
| "lib": ["DOM"], |
| "moduleResolution": "Node16", |
| "module": "esnext", |
| "moduleResolution": "bundler", |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| @@ -4,6 +4,7 @@ |
|---|
| "compilerOptions": { |
| "module": "es2022", |
| "moduleResolution": "bundler", |
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.
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.
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?
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" |
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!
"moduleResolution": "bundler" might be a feature which came out on a later version of typescript, so I think we'll need to bump some versions (I think I need to start doing semver minors on these node builds) and that 👍🏻
Yeah, it’s pretty new (5.0). I noticed some _version fields but I didn’t get how they were used. Do they just control the version of the published npm package?
I'll do it, and I'll ping a few folks who should at least see this coming through:
- @styfle (you might want this change in nextjs too)
- @chriskrycho (this raises the lowest TS support to 5.0, is this something you are intentional about?) we can do a major server for your tsconfig version too
- @dummdidumm (I don't think this should be too breaky for you?)
- I don't think nuxt/remix are used in a more official capacity, so shouldn't worry too much there
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", |
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" |
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?
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.
| @@ -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", |
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!
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?
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
That page is many years out of date and will be deleted / completely rewritten soon.