Casing of output js and js.map files is not consistent.

[Vossekop]

It seems my initial assessment was incorrect (see a bit below what I originally thought happened). It turns out the output filename of a typescript file is not cased the same as the typescript file, but the same as the casing in the reference path another typescript. So if I have one file name CamelCased.ts and one called pascalCased.ts. And I put a reference to camelCased.ts in that last one, this will compile but the output js file will be named camelCased.js and not CamelCased.js as I would have expected.

I don't know if I would call this a bug, but it sure is inconvenient.

[Original]
In a visual studio project containing multiple ts files some start with a capital, and some are all lower case. After the TypeScriptCompile action is called for a file using only lower case, all subsequent file outputs are lower cased, even for ts files that start with a capital.

Files that start with a capital who are compiled before the first lower cased file all have outputs that start with a capital letter.

I know I should be more consistent in my naming, but if you ask me, it's a rather subtle way of forcing me....
[/Original]

[mhegazy]

The compiler currently issues an error of a file name is uses with inconsistent cases only on case sensitive systems. see getSourceFileFromCache.

A good change is to make this controlled by a flag, so that you get errors for inconsistent casing for file references, ensuring that the files are always generated in a consistent manner.

[jkristia]

I would consider this a bug. The compiler (in my opinion) should not be default change the file name casing. Even if I happened to name my file in a non standard way, the compiler should maintain the naming for the js file.
I just moved my project to Linux and was surprised of the many errors I got. It was only then I looked at the generated js files, and noticed the inconsistency in the generated file names

[mhegazy]

@jkristia the problem is getting the actual file name from disk can be expensive, and most of the users do not care about it. this is why the compiler uses the first name of the file it encounters to identify it, be it on the command line, ///reference or import. I would assume that you have some inconsistent casing for file references in your project (either build script or /// reference); would me earlier suggestion of adding a flag to ensure you really reference all files consistently not work for you?

[bleiddyn]

This issue caused me a few hours of confusion as well. If the file system check is expensive, perhaps we could add a fallback to case-insensitive when the compiler has trouble finding the file?

As an aid for people who have the same issue, the compiler error I was getting said, rather unhelpfully, "Module cannot be aliased to a non-module type."

[ghost]

+1 million - One of our team members is having exactly the same problem and has been trying to fix this for the last hour with no luck.

[benliddicott]

Is a filesystem check actually that expensive? This has been profiled?
See also #3626
These sorts of issues seem trivial but occur regularly and cost hours of lost work to fix.

A few days ago I spent two hours chasing down package.config began with BOM - worked on my machine not on Azure. Two hours

[vladima]

#5275 introduces a flag forceConsistentCasingInFileNames - when it is set compiler will report an error if some file has multiple references with inconsistent casing inside the program

[vladima]

fixed in e811fec

[mhegazy]

The fix should be in typescippt@next tonight. Use the new --forceConsistentCasingInFileNames command line argument to make sure you are catching casing issues consistently.