Skip to content
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

Merged
merged 8 commits into from
Jun 27, 2023

Conversation

andrewbranch
Copy link
Collaborator

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",
Copy link
Collaborator Author

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",
Copy link
Collaborator Author

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.

Copy link
Collaborator Author

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.

Copy link

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?

"target": "es2019",

"strict": true,
"esModuleInterop": true,
"skipLibCheck": true,
"forceConsistentCasingInFileNames": true,
"moduleResolution": "node"
"moduleResolution": "node16"
Copy link
Collaborator Author

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.

@orta
Copy link
Member

orta commented Jun 22, 2023

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 👍🏻

@andrewbranch
Copy link
Collaborator Author

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?

@orta
Copy link
Member

orta commented Jun 22, 2023

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

@dummdidumm
Copy link
Contributor

Svelte change looks good to me 👍

@@ -11,7 +11,7 @@
"noEmit": true,
"esModuleInterop": true,
"module": "esnext",
"moduleResolution": "node",
"moduleResolution": "bundler",
Copy link
Contributor

@styfle styfle Jun 23, 2023

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"
Copy link
Contributor

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?

Copy link

@jakebailey jakebailey Jun 23, 2023

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",
Copy link
Contributor

@chriskrycho chriskrycho Jun 23, 2023

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!

Copy link
Member

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?

Copy link
Contributor

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:

Suggested change
"_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).

@orta
Copy link
Member

orta commented Jun 27, 2023

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

@orta orta merged commit 014e892 into tsconfig:main Jun 27, 2023
1 check passed
@andrewbranch
Copy link
Collaborator Author

Thanks all!

@orta
Copy link
Member

orta commented Jul 3, 2023

For folks coming to this thread trying to figure to some of the types, I'd recommend looking at https://arethetypeswrong.github.io/

@joeythomaschaske
Copy link

Ran into a ton of problems with this change. Typescript recommends using node as the moduleResolution value

https://www.typescriptlang.org/docs/handbook/module-resolution.html#module-resolution-strategies

Note: node module resolution is the most-commonly used in the TypeScript community and is recommended for most projects. If you are having resolution problems with imports and exports in TypeScript, try setting moduleResolution: "node" to see if it fixes the issue.

@andrewbranch
Copy link
Collaborator Author

That page is many years out of date and will be deleted / completely rewritten soon.

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.

8 participants