Closed andrewbranch closed 1 year ago
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:
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 👍
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 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.
That page is many years out of date and will be deleted / completely rewritten soon.
Per https://github.com/microsoft/TypeScript/pull/54567 and https://github.com/microsoft/TypeScript/issues/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.