Suggestion: case-sensitive imports

[ccorcos]

TypeScript Version: 2.7.0-dev.201xxxxx

My mac does not have case sensitive imports. That is you can import the file x.js as ./X.js and everything will work. However, our servers run on linux (like most) and I got a runtime exception that took down the whole server because linux imports are case sensitive.

I think this would be an awesome addition to Typescript to prevent fatal mistakes that are hard to catch like this one.

Related Issues:

#14460

[mhegazy]

--forceConsistentCasingInFileNames should catch some of the scenarios involved here. it does not catch all of them though.

[ccorcos]

Oh interesting. I misunderstood what that meant. It doesn't stop you from creating a new file and importing it in a single place with the wrong case though.

[Jessidhia]

There actually is an option that can be given to the tsservice API (useCaseSensitiveFileNames: () => false) to make it be strict with those -- the problem is that it seems that, somewhere, internally, imports are converted to all lower case before they are resolved, which makes things impossible to compile.

[mhegazy]

@Kovensky there are two parts involved, the comparisons which is managed by useCaseSensitiveFileNames and the file system operations. ideally u want the lookup for a module with the wrong case to fail all the time, and not only on a case-sensitive file system. Ideally you want --forceConsistentCasingInFileNames to get fs.realPath and verify it does match the module name used to locate it.

[mhegazy]

I should add the reason why we did not do that is realPath has negative perf implications.

[ccorcos]

I see. Well it sounds like you guys know what you're doing 👍

It looks like a decent performance hit everywhere I've checked. There's a webpack plugin but it makes several calls to the filesystem:

https://github.com/Urthen/case-sensitive-paths-webpack-plugin/blob/master/index.js

I'm not sure how the TypeScript internals work, but it seems like the performance hit wouldn't be too bad if it were a compile-time check on the import statements rather than actually forcing an error on importing the file. At the very least, we can document it and improve it over time.

[tomgruner]

Can I upvote this issue?

I spent hours trying to figure out why my TeamCity build was failing only to realize that the project had some imports that were the wrong case!

Quite an unexpected gotcha as I thought OSX would not import the file if it was the wrong case.

[brandonaaskov]

Just to echo the others here, we were able to run our codebase locally on our macs but it fell over on Heroku because of the wrong casing for the filename, which wasn't obvious and continues to be something we have to keep a keen eye out for (aka old school linting).

[briandesousa]

Similar experience here with a build succeeding on Windows 10 and failing on RHEL 7.6 with a "Cannot find module" error. Took a while to figure out it was a case error on the import. I also tried using the forceConsistentCasingInFileNames setting in my tsconfig.json but it did not catch this.

[vcfvct]

Same here. We have similar issue when using decorators where Reflect.js is case sensitive. Our Type-Graphql keeps complaining duplicated Types registered. Spent several hours finding out it is due to the import which has a uppercase but still compiles.

[shaunluttin]

I should add the reason why we did not do that is realPath has negative perf implications.

Make it opt-in with a flag like enforceCaseSensitiveFileSystemWithSlowerCompilerPerformance.

[joshghent]

Had this issue a lot lately since we build locally which works and then attempt to build in docker which fails. A flag or something similar that would catch these scenarios would be ideal 👍Is the actual issue here that there is a bug with forceConsistentCasingInFileNames not catching everything?