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.
Would forceConsistentCasingInFileNames help? https://www.typescriptlang.org/docs/handbook/compiler-options.html
@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.
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!
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).
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?
Most helpful comment
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 becauseBluebirdshould bebluebird. Maybe there is a setting we are missing in our setup?