Closed wjhsf closed 2 weeks ago
Can you specify exactly one config which you think should behave differently? We're also not super keen on running .sh
files; a concrete set of flat files which we can copy locally would be preferred.
Here's a proper repo you can clone. It's not quite flat because typeRoots
needs a directory structure.
This is the tsconfig.json
from the repo:
{
"files": ["index.ts"],
"compilerOptions": {
"noEmit": true,
// When "typeRoots" is not specified, this project has 8 compiler errors.
// When "typeRoots" is specified, this project has 1 compiler error.
// "typeRoots": ["./node_modules/@types"],
"module": "Node16",
"moduleResolution": "Node16",
// Preserve/Node10, Preserve/Bundler, and ES2015+/Bundler all have
// differences in behavior depending on the presence of "typeRoots".
// "moduleResolution": "Node10",
// "moduleResolution": "Bundler"
// "module": "Preserve",
// "module": "ES2015",
// "module": "ES2020",
// "module": "ES2022",
// "module": "ESNext",
}
}
I also noticed that different combinations of "type": "module"
or "type": "commonjs"
in the root package.json
and in typeRoots/pkg/package.json
result in different errors being reported when you have typeRoots
set in the tsconfig. That's expected behavior. However, if you don't have typeRoots
set, then the errors are always the same. Which seems weird.
Root package | typeRoots package |
Errors |
---|---|---|
cjs | cjs | TS2307 |
cjs | esm | TS1479, TS1479, TS1479, TS1479, TS1479, TS1479, TS1479, TS2307 |
esm | cjs | TS2307, TS2307, TS2307, TS2307 |
esm | esm | TS2307, TS2307, TS2307, TS2307 |
When typeRoots
is not specified, the set of errors is "TS2307, TS2307, TS2307, TS2307, TS2307, TS2307, TS2307, TS2307" in all four scenarios.
Perhaps unsurprisingly, I've found that it's the presence of "exports"
in the package.json that is causing the issue. When that key is removed, then the behavior of tsc
is the same regardless of whether typeRoots
is specified.
I think this is a duplicate of https://github.com/microsoft/TypeScript/issues/47444. I tried to fix it at https://github.com/microsoft/TypeScript/pull/58638 and the breaks looked untenable. It may be worth experimenting with resolving "exports"
first and falling back to resolving "types"
, but I held off since non-type-reference module resolution does not continue with fallbacks if "exports"
resolution fails, and keeping that consistency with the spec is a plus.
Marking as a duplicate and scheduling another crack at #47444 for 5.8. (Any fix we can possibly do here is going to be a breaking change, so itβs too late for 5.7.)
This issue has been marked as "Duplicate" and has seen no recent activity. It has been automatically closed for house-keeping purposes.
π Search Terms
typeRoots, module resolution, moduleResolution, bundler
π Version & Regression Information
Preserve
since 5.4.2)β― Playground Link
No response
π» Code
No response
π Actual behavior
Setting
typeRoots
to./node_modules/@types
changes how modules are resolved when using the following compiler options:moduleResolution: Node16, module: Node16
moduleResolution: Node10, module: Preserve
moduleResolution: Bundler, module: ES2015 | ES2020 | ES2022 | ESNext | Preserve
π Expected behavior
Setting
typeRoots
to./node_modules/@types
should not change how modules are resolved.Additional information about the issue
Clone this gist and execute
setup.sh
to see a minimal reproduction. It sets up a package with various export types, and tries to compile a file with corresponding imports using variousmodule
/moduleResolution
combinations. Not all imports are expected to work for all combinations, but the errors are expected to be the same regardless of whethertypeRoots
is specified. If the errors are different, the script will log the errors along with the compiler options used. (No output from the script means there were no mismatched errors.)Sample output: