Tslint: Rule for case sensitive imports

[borekb]

Some of our builds fail because import * from './module' is lowercase while the file on the disk is uppercase (Module.ts). This is OK on Windows and macOS but not on Linux.

Maybe it would be a good candidate for a new rule?

[adidahiya]

Sounds expensive since you'd have to read file names from disk. I wouldn't want that in the core rules. Instead, you might consider writing a rule that validates module names of relative imports (perhaps with a regex).

[seanzer]

eslint has a couple of plugins that do this, but it would be nice to have it integrated with tslint: https://www.npmjs.com/package/eslint-plugin-dependencies

[seanzer]

I just found out typescript has this feature built in to the compiler:

https://www.typescriptlang.org/docs/handbook/compiler-options.html
--forceConsistentCasingInFileNames

[borekb]

Thanks, I didn't know about this, adding it to all our tsconfig.jsons now :)

[adidahiya]

Closing this out as compiler options are generally preferred to lint rules, especially for something related to I/O. I can reopen if there's widespread interest in this.

[roopaprabhun]

--forceConsistentCasingInFileNames does not work. even when my file name is in incorrect case, compilation with this option as true, does not fail.

[ajafff]

@roopaprabhun you may want to report this bug in the TypeScript repo to get this fixed.

[saitonakamura]

--forceConsistentCasingInFileNames works in different way. If there will be multiple imports imports to the same file with inconsistent casing, e.g. import b from 'bluebird' and import b from 'Bluebird' it will throw an error. So it doesn't prevent from wrong spelling when you're writing this import in the first place.

[a7madgamal]

so according to the last comment, the feature request is still relevant, right?

[thw0rted]

Yes, it's relevant, and I just got bitten by this. I was updating a DT definition, imported from "GeoJSON" (which is the class name, not the correctly-cased module name), and it worked on my Windows dev box but failed Travis (which is presumably on Linux). I'd love to catch dumb oversights like this at lint-time, whether through a linter option or a compiler option.

[TroyLDay]

Also bitten.

[thw0rted]

Just realized nobody has brought this to the attention of @adidahiya , so: hello! Could we get this re-opened please?

[johnwiseheart]

Reopening to encourage more discussion - I agree with @adidahiya that I don't think this should be a core rule due to perf implications. That said, I think given the interest that it could still be worthwhile to implement.

[thw0rted]

I don't have a horse in the race as far as where it gets checked, I just want to make sure that it fails some time before I commit my code. For DT updates, it could be specific to dtslint; for my own code I'd be fine if the linter didn't catch it but the AOT compiler did -- just something that takes a look at my import and says "hey dummy, your case is wrong"... other than a user from another platform inexplicably not finding a dep.

[JoshuaKGoldberg]

Note: per #4534, this issue will be closed in less than a month if no PR is sent to add the rule. If you _really_ need the rule, custom rules are always an option and can be maintained outside this repo!

[JoshuaKGoldberg]

💀 _It's time!_ 💀

TSLint is being deprecated and no longer accepting pull requests for new rules. See #4534. 😱

If you'd like to see this rule implemented, you have two choices:

• Recommended: Use typescript-eslint to lint your TypeScript code with ESLint ✅
• Legacy: Write it as a custom TSLint rule 🤷‍♂️

👋 It was a pleasure open sourcing with you!

_If you believe this message was posted here in error, please comment so we can re-open the issue!_