-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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
Make module
control impliedNodeFormat
and moduleResolution
control just module resolution
#54788
Conversation
8118262
to
081a381
Compare
src/testRunner/unittests/tscWatch/forceConsistentCasingInFileNames.ts
Outdated
Show resolved
Hide resolved
@typescript-bot pack this |
Heya @DanielRosenwasser, I've started to run the extended test suite on this PR at 081a381. You can monitor the build here. |
Heya @DanielRosenwasser, I've started to run the diff-based top-repos suite on this PR at 081a381. You can monitor the build here. |
Heya @DanielRosenwasser, I've started to run the diff-based user code test suite (tsserver) on this PR at 081a381. You can monitor the build here. Update: The results are in! |
Heya @DanielRosenwasser, I've started to run the parallelized Definitely Typed test suite on this PR at 081a381. You can monitor the build here. Update: The results are in! |
Heya @DanielRosenwasser, I've started to run the tarball bundle task on this PR at 081a381. You can monitor the build here. |
Heya @DanielRosenwasser, I've started to run the diff-based top-repos suite (tsserver) on this PR at 081a381. You can monitor the build here. Update: The results are in! |
Heya @DanielRosenwasser, I've started to run the diff-based user code test suite on this PR at 081a381. You can monitor the build here. Update: The results are in! |
Hey @DanielRosenwasser, I've packed this into an installable tgz. You can install it for testing by referencing it in your
and then running There is also a playground for this build and an npm module you can use via |
84a06c3
to
d3c08b2
Compare
@DanielRosenwasser Here are the results of running the user test suite comparing Everything looks good! |
@DanielRosenwasser Here are the results of running the user test suite comparing There were infrastructure failures potentially unrelated to your change:
Otherwise... Something interesting changed - please have a look. Details
|
Hey @DanielRosenwasser, it looks like the DT test run failed. Please check the log for more details. |
@DanielRosenwasser Here are the results of running the top-repos suite comparing Something interesting changed - please have a look. DetailsServer exited prematurely with code unknown and signal SIGABRT
Affected reposredwoodjs/redwoodRaw error text:RepoResults4/redwoodjs.redwood.rawError.txt in the artifact folder
Last few requests{"seq":1906,"type":"request","command":"getOutliningSpans","arguments":{"file":"@PROJECT_ROOT@/packages/auth-providers/azureActiveDirectory/web/jest.config.js"}}
{"seq":1907,"type":"request","command":"navto","arguments":{"searchValue":"a","maxResultCount":256}}
{"seq":1908,"type":"request","command":"navto","arguments":{"searchValue":"A_E","maxResultCount":256}}
{"seq":1909,"type":"request","command":"definitionAndBoundSpan","arguments":{"file":"@PROJECT_ROOT@/packages/auth-providers/azureActiveDirectory/web/jest.config.js","line":1,"offset":5}}
Repro steps
|
Co-authored-by: Sheetal Nandi <[email protected]>
Looks like you're introducing a change to the public API surface area. If this includes breaking changes, please document them on our wiki's API Breaking Changes page.\n\nAlso, please make sure @DanielRosenwasser and @RyanCavanaugh are aware of the changes, just as a heads up. |
Seriously? Well, at least the bot is confirmed working... |
|
||
[91merror[0m[90m TS2318: [0mCannot find global type 'String'. | ||
|
||
[91merror[0m[90m TS6053: [0mFile '/a/lib/lib.es2022.full.d.ts' not found. |
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.
Oh man.. this is getting tricky,. i suggested wrong lib file? :( Sorry
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 diff is so hard to look at locally because of the terminal color codes in the actual content, so I’m not paying too much attention to what I’m pushing 😅 Easier to look on GH
Co-authored-by: Sheetal Nandi <[email protected]>
@@ -1,7 +1,9 @@ | |||
error TS5095: Option 'bundler' can only be used when 'module' is set to 'es2015' or later. | |||
error TS5109: Option 'moduleResolution' must be set to 'NodeNext' (or left unspecified) when option 'module' is set to 'NodeNext'. | |||
|
|||
|
|||
!!! error TS5095: Option 'bundler' can only be used when 'module' is set to 'es2015' or later. |
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.
Wait... so module
now controls weather we interpret files as cjs/esm, but you still can't combine that with bundler
? I thought the point of this was basically to make it so bundler
could assimilate the mode-swapping interpretation? So you could mimic bundlers that more closely mimiced node?
Isn't allowing module: nodenext
+ moduleResultion: bundler
for modern-node-like bundler environments kinda the goal here?
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.
(Since this format data directly controls, eg, how we interpret default
imports, the distinction may be material)
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.
Yeah, that's the linked issue #54102 - shouldn't we just fix that, while we're here? It should be removing this error, right?
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.
Yeah, that is the ultimate goal, but I don’t think --module nodenext
is the right thing to combine with --moduleResolution bundler
. --module nodenext
implies that CJS-mode files actually get emitted as CJS, which doesn’t make sense in the context of most bundlers. In bundlers, the choice is not between CJS and ESM; the default is ESM with Babel-like interop and .mjs
files just disable the Babel-like interop in favor of Node’s always-synthesize-a-default interop. It can be hard to tell the difference between “ESM with Babel-like interop” and “it’s actually just CJS with esModuleInterop
under the hood,” but we can tell there’s a difference because
- top-level wait is always allowed (by those that support it at all)
- the module format does not affect the
"imports"
/"exports"
conditions used in module resolution—import statements always have"import"
; they’re not secretly transformed torequire
first in CJS-mode files - some bundlers refuse to process
require
calls outside of node_modules at all
Additionally, the transform for import foo = require(...)
to a createRequire
call under --module nodenext
is highly Node-specific and would fail under I think every bundler (maybe Webpack has compat for that; they do the most complete job at imitating Node).
So, my thinking for addressing #54102 is that either there needs to be a different module
mode for these bundlers that have Node-like interop behavior (in which case this PR is necessary but not sufficient), or the thing that makes us set impliedNodeFormat
in the first place needs to be decoupled from module
(in which case this PR is not necessary, but doesn’t hurt anything as an interim step toward the eventual goal). Either way, we’ll need to move it off of moduleResolution
in order to resolve #54102, and module
will imply an impliedNodeFormat
-setting behavior if it doesn’t directly control it.
Follow-up to #54567. This helps establish a mental model that's easier to document, and gives us more room to fix stuff like #54102.