build: update packages to use more modern moduleresolution options #1770
Conversation
This file contains 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
This change updates tsconfigs across all packages to use more up to date `module` and `moduleResolution` options. For all packages that were being built as `commonjs` modules with node `moduleResolution`, they've been updated to use `nodenext`. I also took the opportunity to re-organize the tsconfigs at the packages level to make their names more accurate. Previously the main `packages/tsconfig.json`, which is what the `build:esm` command targetted, referenced all package's tsconfigs, while a `packages/tsconfig.cjs.json` only referenced the cjs tsconfig from the react package. However, all packages' tsconfigs _except_ for the react tsconfig are building cjs. So having a command that's called `build:esm` run all cjs builds and one esm build didn't really do what the name would suggest. So I reversed that construct. Now `packages/tsconfig.json` still references all of the packages tsconfig, except for the react package, it references the `tsconfig.cjs`, and I renamed the `packages/tsconfig.cjs.json` to `packages/tsconfig.esm.json` and have it only referencing the main react package tsconfig. The net / net is that `build:esm` is only building esm output and `build:cjs` is only building cjs output. Similarly, all package level tsconfigs are inheriting from packages/tsconfig.options.json, but that config had module and moduleResolution corresponding to the tsconfig in react (the ESM one), and all of the other package tsconfigs were overriding the module and moduleResolution. So I swapped that, so that the base config has the module and moduleResolution that all but on of the packages are using, and had the react tsconfig override that to what it needed to be for esm output. This means fewer tsconfigs are needing to override those options. Lastly, I've done build comparisons for all packages and target, and they all result in the same build output as they did before these changes.
michaelfaith
requested review from
JakeLane,
pancaspe87,
liamqma,
dddlr and
zesmith2
as code owners
|
✅ Deploy Preview for compiled-css-in-js canceled.
|
JakeLane
approved these changes
Dec 22, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Following: #1760 (comment)
This change updates tsconfigs across all packages to use more up to date
moduleandmoduleResolutionoptions. For all packages that were being built ascommonjsmodules withnodemoduleResolution, they've been updated to usenodenext.I also took the opportunity to re-organize the tsconfigs at the packages level to make their names more accurate. Previously the main
packages/tsconfig.json, which is what thebuild:esmcommand targeted, referenced all package's tsconfigs, while apackages/tsconfig.cjs.jsononly referenced the cjs tsconfig from the react package. However, all packages' tsconfigs except for the react tsconfig are building cjs. So having a command that's calledbuild:esmrun all cjs builds and one esm build didn't really do what the name would suggest. So I reversed that construct. Nowpackages/tsconfig.jsonstill references all of the packages tsconfig, except for the react package, it references thetsconfig.cjs, and I renamed thepackages/tsconfig.cjs.jsontopackages/tsconfig.esm.jsonand have it only referencing the main react package tsconfig (which is the only esm config).The net / net is that
build:esmis only building esm output andbuild:cjsis only building cjs output.Similarly, all package level tsconfigs are inheriting from packages/tsconfig.options.json, but that config had
moduleandmoduleResolutioncorresponding to the tsconfig in react (the ESM one), and all of the other package tsconfigs were overriding themoduleandmoduleResolution. So I swapped that, so that the base config has the module and moduleResolution that all but on of the packages are using, and had the react tsconfig override that to what it needed to be for esm output. This means fewer tsconfigs are needing to override those options.Lastly, I've done build comparisons for all packages and targets, and all result in the exact same build output as they did before these changes, except for one file.
utils/with-pluginwhich has a dynamic import. The old schoolcommonjsmodule didn't support dynamic imports so it transpiled it down to a require and a bunch of additional wiring to give a similar behavior. Innodenextit just uses the dynamic import directly.(left is before, right is after)
All this extra cruft:
Just to support this one
importSo, I'm not sure how you'd like to represent this in the
utilschangelog. All the rest are exactly the same output.