forceConsistentCasingInFileNames does not always work with paths compiler option

[stephenbrady]

TypeScript Version: 2.4.2

Code

// Base tsconfig at /Users/a_user/a_repo/core.json
{
  "compilerOptions": {
    "forceConsistentCasingInFileNames": true,
    "baseUrl": "",
    "paths": {
      "*": [ "*", "src/*" ]
    }
  }
}

// tsconfig at /Users/a_user/a_repo/tsconfig.json
{
  "extends": "./core"
}

// Source file in /Users/a_user/a_repo/src/foo.ts
const v = 1;
export default v;

// Source file in /Users/a_user/a_repo/src/bar.ts
import v from "foo";

Expected behavior:
No compiler errors/warnings

Actual behavior:

error TS1149: File name '/Users/a_user/a_repo/src/foo.ts' differs from already included file name '/users/a_user/a_repo/src/foo.ts' only in casing.

---

This is running on OS X 10.9.5 (default case-insensitive HFS file system).

I am only able to reproduce the issue when using configuration inheritance. Using an absolute path with the expected casing for baseUrl resolves the issue.

This issue is filed off of these remarks: #17542 (comment)

[aluanhaddad]

Thank you for filing this. I see the exact same behavior. Interestingly, if I set baseUrl in the extending tsconfig, it also resolves the error.

[afshinm]

I have the same problem on mac OS, node 7.6.0.

[arackaf]

Reproduced on Windows 10 as well. Interestingly, we don't even have paths set. Full tsconfig:

{
    "compilerOptions": {
        "target": "esnext",
        "baseUrl": "./src",
        "jsx": "react",
        "allowSyntheticDefaultImports": true,
        "allowUnreachableCode": true,
        "allowJs": true,
        "moduleResolution": "node",
        "module": "es2015",
        "experimentalDecorators": true,
        "forceConsistentCasingInFileNames": true,
        "lib": ["es2015", "dom"],
        "typeRoots" : ["./typings/modules", "./node_modules/@types"]
    },
    "include": [
        "./src/**/*.ts",
        "./src/**/*.tsx",
        "./src/**/*.js",
        "./src/**/*.jsx",
        "./test/**/*.ts*"
    ],
    "exclude": [
        "./node_modules/**/*",
        "./dist/**/*",
        "./src/assets/**/*",
        "./src/build/**/*"
    ]
}

[aluanhaddad]

@arackaf it is --baseUrl that causes the issue. When it is inherited, it seems to get resolved in such a way that the resulting paths begin with its lowercase variant. the simplest work around currently is to specify the base URL a second time in the inheriting configuration.

[arackaf]

What do you mean "inherited" ? I only have one tsconfig file - what's being inherited where?

[aluanhaddad]

Sorry, it's not in the issue title but the op states that the issue can only be reproduced when using configuration inheritance. This has been my experience as well.

I'm also running Windows 10, professional x64

[arackaf]

Oh interesting. Well I may have stumbled onto a different repro of the same bug. I only have one tsconfig.json in my project, but this still fails for me. I ran a search on my file system, and the only other tsconfig file anywhere is in node_modules, which I've explicitly excluded.

[mhegazy]

OP should be addressed by #18058.

@arackaf can you share more context about your issue, preferably in a new ticket.

[arackaf]

@mhegazy When is the fix in 18058 going to show up in a new version? If that doesn't fix my issue, then sure, I'll open a new ticket, hopefully with a minimal repro

[mhegazy]

When is the fix in 18058 going to show up in a new version?

it should be in today's typescript@next.

[arackaf]

Cool, but when do you expect the next regular release on npm? Want to try that on my work repo. We definitely can't be running typescript@next in prod :)

[mhegazy]

should be in 2.6, scheduled for October

[arackaf]

Oh my - seems I missed 2.5! :D

[jamietre]

This is still happening to me in 2.7.1 on mac OS. I'm using inherited tsconfigs, it doesn't matter where baseUrl is specified, tried all permutations.

All the errors reported are for ambient d.ts typings and module declarations, under node_modules/@types and our own internal types folder, which seems relevant. The /Users root folder lowercased.

[weswigham]

A similarish bugfix related to consistent casing shipped in 2.7.2, which as it happens released today. Does it fix your issues?

[aluanhaddad]

@weswigham yes! It fixes the issue. It is consistently observed in previous versions but upon switching to 2.7.2 all works correctly.
Thank you very much.

[jamietre]

Works for me too! Talk about instant gratification..