forceConsistentCasingInFileNames: true and moduleResolution: Node16 break type reference directives on macOS if there are capital letters in the path

[alecmev]

Bug Report

🔎 Search Terms

forceConsistentCasingInFileNames, moduleResolution, Node16, NodeNext, type reference, "differs from already included file name", "only in casing". Relevant issues (all resolved and predating Node16): #16875, #20003, #17617, #9824

🕗 Version & Regression Information

This is the behavior in every version I tried, and I haven't found any issues or FAQ entries about this. Tested only on 4.8.2, sorry. Looks like this might be recent regression after all.

⏯ Playground Link / 💻 Code

I can't reproduce this in neither the playground nor the workbench nor even Linux. The problem appears only on macOS. Here's a repro: https://github.com/alecmev/typescript-type-reference-lowercase-repro Just npm i and npx tsc.

🙁 Actual behavior

index.ts:2:26 - error TS1149: File name '/users/foo/repro/node_modules/@types/react/index.d.ts' differs from already included file name '/Users/Foo/repro/node_modules/@types/react/index.d.ts' only in casing.
  The file is in the program because:
    Type library referenced via 'react' from file '/Users/Foo/repro/node_modules/@babylonjs/inspector/babylon.inspector.module.d.ts'
    Imported via "react" from file '/Users/Foo/repro/node_modules/@babylonjs/inspector/babylon.inspector.module.d.ts' with packageId '@types/react/index.d.ts@18.0.17'

Note /users/foo vs. /Users/Foo.

🙂 Expected behavior

This is valid code and it works on Linux and/or without moduleResolution: Node16. An unnecessary toLowerCase happens somewhere, but I can't really debug this further since I use Linux and had to use my colleague's computer to create the repro. The title of the issue is only a guess, I don't know the root of the issue.

[milesj]

Same settings here, and I'd also like to note that we're seeing this a ton after upgrading to v4.8. Turning off forceConsistentCasingInFileNames fixes the problem for now.

src/bin.ts:3:19 - error TS1261: Already included file name '/users/milesj/projects/web/node_modules/@types/yargs/index.d.ts' differs from file name '/Users/milesj/Projects/web/node_modules/@types/yargs/index.d.ts' only in casing.
  The file is in the program because:
    Imported via 'yargs' from file '/Users/milesj/Projects/web/packages/mono-env/src/bin.ts' with packageId '@types/yargs/index.d.ts@17.0.11'
    Entry point for implicit type library 'yargs' with packageId '@types/yargs/index.d.ts@17.0.11'
  File is CommonJS module because '/users/milesj/projects/web/node_modules/@types/yargs/package.json' does not have field "type"

[fatcerberus]

This seems related to #45509 -> #45096 -> #10340

[fatcerberus]

This is a particularly nasty manifestation of #45096 because the only part of the path the compiler thinks differs in case (/Users/Foo) isn't even a canonical part of the project. It's almost like the bad old days when having spaces anywhere in a path would break everything. 😝

[sheetalkamat]

Do you see this in vscode as well.. Can you run tsc with --traceResolution and share the logs to look into this further. Thanks

[alecmev]

@milesj Can you test this, if you have a spare minute, please? If not - all good, I'll have access to a Mac tomorrow.

[milesj]

Sure, here's some trace output. There's a lot of it so I'm only including the section related to my error above.

======== Resolving module 'yargs' from '/Users/milesjohnson/Projects/web/packages/mono-env/src/bin.ts'. ========
Explicitly specified module resolution kind: 'NodeNext'.
'baseUrl' option is set to '/Users/milesjohnson/Projects/web', using this value to resolve non-relative module name 'yargs'.
'paths' option is specified, looking for a pattern to match module name 'yargs'.
'baseUrl' option is set to '/Users/milesjohnson/Projects/web', using this value to resolve non-relative module name 'yargs'.
Resolving module name 'yargs' relative to base url '/Users/milesjohnson/Projects/web' - '/Users/milesjohnson/Projects/web/yargs'.
Loading module as file / folder, candidate module location '/Users/milesjohnson/Projects/web/yargs', target file type 'TypeScript'.
File '/Users/milesjohnson/Projects/web/yargs.ts' does not exist.
File '/Users/milesjohnson/Projects/web/yargs.tsx' does not exist.
File '/Users/milesjohnson/Projects/web/yargs.d.ts' does not exist.
Directory '/Users/milesjohnson/Projects/web/yargs' does not exist, skipping all lookups in it.
File '/users/milesjohnson/projects/web/packages/mono-env/src/package.json' does not exist according to earlier cached lookups.
File '/users/milesjohnson/projects/web/packages/mono-env/package.json' exists according to earlier cached lookups.
Loading module 'yargs' from 'node_modules' folder, target file type 'TypeScript'.
Directory '/Users/milesjohnson/Projects/web/packages/mono-env/src/node_modules' does not exist, skipping all lookups in it.
File '/Users/milesjohnson/Projects/web/packages/mono-env/node_modules/yargs.ts' does not exist.
File '/Users/milesjohnson/Projects/web/packages/mono-env/node_modules/yargs.tsx' does not exist.
File '/Users/milesjohnson/Projects/web/packages/mono-env/node_modules/yargs.d.ts' does not exist.
Directory '/Users/milesjohnson/Projects/web/packages/mono-env/node_modules/@types' does not exist, skipping all lookups in it.
Directory '/Users/milesjohnson/Projects/web/packages/node_modules' does not exist, skipping all lookups in it.
Found 'package.json' at '/Users/milesjohnson/Projects/web/node_modules/yargs/package.json'.
'package.json' does not have a 'typesVersions' field.
File name '/users/milesjohnson/projects/web/node_modules/yargs/index.cjs' has a '.cjs' extension - stripping it.
File '/users/milesjohnson/projects/web/node_modules/yargs/index.cts' does not exist.
File '/users/milesjohnson/projects/web/node_modules/yargs/index.d.cts' does not exist.
File name '/users/milesjohnson/projects/web/node_modules/yargs/index.cjs' has a '.cjs' extension - stripping it.
File '/users/milesjohnson/projects/web/node_modules/yargs/index.cts' does not exist.
File '/users/milesjohnson/projects/web/node_modules/yargs/index.d.cts' does not exist.
package.json scope '/Users/milesjohnson/Projects/web/node_modules/yargs' has invalid type for target of specifier '.'
Found 'package.json' at '/Users/milesjohnson/Projects/web/node_modules/@types/yargs/package.json'.
'package.json' has a 'typesVersions' field with version-specific path mappings.
'package.json' does not have a 'typesVersions' entry that matches version '4.8'.
File '/users/milesjohnson/projects/web/node_modules/@types/yargs/index.d.ts' exist - use it as a name resolution result.
Resolving real path for '/users/milesjohnson/projects/web/node_modules/@types/yargs/index.d.ts', result '/Users/milesjohnson/Projects/web/node_modules/@types/yargs/index.d.ts'.
======== Module name 'yargs' was successfully resolved to '/users/milesjohnson/projects/web/node_modules/@types/yargs/index.d.ts' with Package ID '@types/yargs/index.d.ts@17.0.11'. ========

[josundt]

I can confirm that the same problem happens on Windows (11).
I experience the same after upgrading our project from TypeScript 4.7.4 to 4.8.2.
forceConsistentCasingInFileNames is set to true, and moduleResolution is set to NodeNext in our project.

I have also tested the code in alecmev's "repro" repository, the same happens on my Windows 11 machine when the local git working directory has uppercase characters in the path.

As mentioned by alecmev, the error message indicates that some unwanted path.toLowerCase() has taken place in the module resolution process ahead of the forceConsistentCasingInFileNames path comparison.

I have temporarily disabled forceConsistentCasingInFileNames as a temporary fix, but this compiler option is useful to ensure code written on a Windows computer will also work on Linux. Hoping for a hotfix.

[fatcerberus]

@josundt's Your observation/analysis suggests nodenext builds would be completely broken on Linux if the project's full path has any uppercase characters in it...

[josundt]

@fatcerberus I just now tested to typescript-compile (tsc) alecmev's "repro" repository running node/npm on Ubuntu through WSL on Windows 11.

The TypeScript compiler does NOT encounter any errors here - even when the path has mixed case characters in the path name.

[josundt]

@fatcerberus And BTW: The problem is just the same with moduleResolution: NodeNext and moduleResolution: Node16 on Windows 11, while no problems on Ubuntu/WSL

[fatcerberus]

Huh, so it's not just blindly lowercasing paths. This is a strange bug indeed.

[wight554]

I can confirm that the same problem happens on Windows (11). I experience the same after upgrading our project from TypeScript 4.7.4 to 4.8.2. forceConsistentCasingInFileNames is set to true, and moduleResolution is set to NodeNext in our project.

I have also tested the code in alecmev's "repro" repository, the same happens on my Windows 11 machine when the local git working directory has uppercase characters in the path.

As mentioned by alecmev, the error message indicates that some unwanted path.toLowerCase() has taken place in the module resolution process ahead of the forceConsistentCasingInFileNames path comparison.

I have temporarily disabled forceConsistentCasingInFileNames as a temporary fix, but this compiler option is useful to ensure code written on a Windows computer will also work on Linux. Hoping for a hotfix.

can still reproduce with typescript 4.8.3 + windows 11:

src/store/postState.ts:4:26 - error TS1261: Already included file name 'c:/users/wight/documents/blog-template/src/services/post.ts' differs from file name 'C:/Users/wight/Documents/blog-template/src/services/post.ts' only in casing.
  The file is in the program because:
    Imported via '#src/services/post.js' from file 'c:/users/wight/documents/blog-template/src/store/postState.ts' with packageId 'blog-template/src/services/post.ts@0.0.0'
    Matched by include pattern '.' in 'src/tsconfig.json'
    Imported via '#src/services/post.js' from file 'c:/users/wight/documents/blog-template/src/store/postState.ts' with packageId 'blog-template/src/services/post.ts@0.0.0'
  File is ECMAScript module because 'c:/users/wight/documents/blog-template/package.json' has field "type" with value "module"

4 import { getPosts } from '#src/services/post.js';
                           ~~~~~~~~~~~~~~~~~~~~~~~

reproduction here: wight554/blog-template#59

[martincostello]

I've just run into this upgrading from typescript 4.9.5 to 5.0.2.

I have a matrix build for Linux, macOS and Windows, and both macOS and Windows are now failing with the same error. The Linux build is fine though.

  [06:20:06] Error: TypeScript error: d:/a/website/website/src/website/assets/scripts/main.ts(4,21): Error TS1261: Already included file name 'd:/a/website/website/src/website/assets/scripts/view/App.ts' differs from file name 'd:/a/website/website/src/website/assets/scripts/view/app.ts' only in casing.

[sheetalkamat]

@martincostello, I cloned the repo and ran tsc in src/website and dont see any error. Note that with 5.0 forceConsistentCasingInFileNames now defaults to true so this error that wasnt reported part of your setup before will get reported if there is issue with the casing. Your build pipeline runs gulp and i am not sure if its handling it correctly.

[martincostello]

I typically go through npm run build, rather than run tsc directly. As far as I could tell, the casing in Git and in the file match.

[martincostello]

Turning that off explicitly in tsconfig.json does make the error go away though.