Repository navigation
Suggestion: case-sensitive imports #21736
Description
Activity
--forceConsistentCasingInFileNamesshould catch some of the scenarios involved here. it does not catch all of them though.Reacted by Aluan Haddad, Gautam Chitnis and Damien GoldingReacted by Shaun Luttin, kbradl16, beshanoe, yuyujulin, Miguel Lo-A-Foe, John Weisz, 空无, Anders Ramsay and Marcus TurewiczOh 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.
Reacted by Shaun LuttinThere 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.Reacted by Prasanth Vaaheeswaran@Kovensky there are two parts involved, the comparisons which is managed by
useCaseSensitiveFileNamesand 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--forceConsistentCasingInFileNamesto getfs.realPathand verify it does match the module name used to locate it.Reacted by Hong, HeerimI should add the reason why we did not do that is realPath has negative perf implications.
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.
Reacted by 无止休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.
Reacted by Tommi Kivelä, Matt Paul, Brandon Aaskov, kellas, Gautam Chitnis, Brian De Sousa, dip, Simon Edwardsson, calicocook, Will and 24 moreJust 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).
Reacted by Brian De Sousa and John WeiszSimilar 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.
Same here. We have similar issue when using decorators where Reflect.js is case sensitive. Our Type-Graphql keeps complaining duplicated
Typesregistered. Spent several hours finding out it is due to the import which has a uppercase but still compiles.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.Reacted by hn3000, John Weisz, Prasanth Vaaheeswaran, Edward D'Souza and Rob WierzbowskiReacted by Ryan Cavanaugh, Kostiantyn Ko, notaphplover, Andrew Anikin, James Nisbet, Patryk Poźniak, Prasanth Vaaheeswaran and BJ MaldonadoHad 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
forceConsistentCasingInFileNamesnot catching everything?Reacted by Anders Ramsay5 remaining items
Is there any news about this?
Reacted by kbradl16 and Jean ReynosoI have also been bitten by this very silly behavior.
Reacted by Sean LeeI was bitten by this very time consuming bug :(
Reacted by Sean LeeI spent dozens of minutes to find why my Mac all goes well but failed in linux jenkins unit test.
Reacted by Iwan Aucamp, Miguel Lo-A-Foe, Weetbix, EviSONG, MarkZhang and erlanI know this doesn't solve the problem, but wanted to share my opinion.
I'm starting to realize that kebab-case is a very good naming strategy for files. It would avoid these problems. Maybe most of JS devs like me do not like the idea because so many years of using camelCase/TitleCase, but things changed lately with Typescript. You get autocomplete feature out of the box. Why would I name the file the same as the class or component I'm exporting? Looks like Java to me. Also, all lowercase is clearer, much more easy to read.Reacted by Shrihari, EviSONG and Prasanth VaaheeswaranReacted by yuyujulin, Felipe and Rob WierzbowskiStill no updates yet? Same issue here, damn, we took a long time to figure it out.
Reacted by Weetbix, Miquel de Arcayne, Thanh-Quy Nguyen and ssoonanI'd like to work on this.
Hey folks. Seems
forceConsistentCasingInFileNamesis working fine?
Reacted by Mel Green, tomoat, Jinma Yamashita, Anas Jaber and Jingqi ZhangI think the problem is importing external modules with different casing and not just internal references to specific files.
Reacted by Grzegorz Marchwiński, MarkZhang and Misha KonovalovWenlu Wang (@Kingwl) its external module imports (for example
import MuiLink from "@material-ui/core/link";), andforceConsistentCasingInFileNames: truedoes not help, imports are still case insensitive.Reacted by emptygalaxy, HermannGruber, Ming and Luke PageOh. Well Okay. Got the point.
kebab-case ftw. I had low priority PR up for over 2 months -- the issue was the build passed locally (OSX) but failed within the container. We of course took a look at, scratched our heads, and moved on to more important things. This evening I finally spent some time on it .. just wow is all I can say. Unix kids are laughing right now.
forceConsistentCasingInFileNamesdoes not work for importing from external lib.// should be 'koa-bodyparser' import bodyParser from 'koa-bodyParser'
works well on my Mac but failed in my linux CI/CD test.
Reacted by Budi Irawan and Andrea PontrandolfoI have a strange issue that i
forceConsistentCasingInFileNamescomplains on path, but the discrepancy is not on the level of the project, but way higher up:'/Users/sitecore/Sites/feaas-components/node_modules/@ctrl/tinycolor/dist/public_api.d.ts' differs from already included file name '/users/sitecore/sites/feaas-components/node_modules/@ctrl/tinycolor/dist/public_api.d.ts' only in casing.Why would my username on mac os be lowercased on one path and not in another?
TypeScript Version: 2.7.0-dev.201xxxxx
My mac does not have case sensitive imports. That is you can import the file
x.jsas./X.jsand 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