Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion: option to enforce case sensitive imports #14460

Closed
Stevenic opened this issue Mar 5, 2017 · 5 comments
Closed

Suggestion: option to enforce case sensitive imports #14460

Stevenic opened this issue Mar 5, 2017 · 5 comments
Labels
Question An issue which isn't directly actionable in code

Comments

@Stevenic
Copy link

Stevenic commented Mar 5, 2017

I work on the Node version of the BotBuilder SDK and on more than one occasion we've had MAC users of our SDK complain of module load errors. The reason for that is that Windows is case insensitive with regards to import paths where the MAC is case sensitive. Since we develop our SDK using Windows machines it's super easy for us to introduce an error if we get the case wrong in one of our imports. We're not setup to be able to run our unit tests on macs so we currently don't have a great way of catching these issue.

I realize this isn't a TypeScript issue but I thought it could be nice to have a TypeScript compiler option that says all import paths should be case sensitive.

@jwbay
Copy link
Contributor

jwbay commented Mar 5, 2017

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

@Stevenic
Copy link
Author

Stevenic commented Mar 5, 2017

@jwbay does that actually enforce that the casing match the file casing? I read that as ensuring that all file references have the same case. In the early days of TypeScript (pre-1.0) if you had references with different case the file would actually get processed twice. I assumed that flag was to prevent that. I think you're on the right path though.

@Stevenic
Copy link
Author

Stevenic commented Mar 5, 2017

Actually, just tried that and it does help. It's not a perfect solution because it only catches differences in case across imports but it effectively solves the problem so long as you get the case for at least one import correct. Thank you much!

@Stevenic Stevenic closed this as completed Mar 5, 2017
@RyanCavanaugh RyanCavanaugh added the Question An issue which isn't directly actionable in code label Mar 6, 2017
@JoshMcCullough
Copy link

I think this should still be open and considered. If we don't enforce or at least warn about case mismatches in import statements at transpile time, then if we bundle, we may run into issues. E.g. SystemJS does not normalize import paths, so if the TS file says import { X } from "blah/X"; but the path is actually blah/x, this will fail at runtime (which is the worst time, of course).

@mtrubs
Copy link

mtrubs commented Dec 14, 2017

I actually just ran into this as well. On my mac I did an import { X } from "Bluebird"; accidentally (which runs fine) and then when deployed to an ubuntu system (luckily not prod yet) it threw lots of errors because Bluebird should be bluebird. Maybe there is a setting we are missing in our setup?

@microsoft microsoft locked and limited conversation to collaborators Jun 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Question An issue which isn't directly actionable in code
Projects
None yet
Development

No branches or pull requests

5 participants