forceConsistentCasingInFileNames does not always work with paths compiler option

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)

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.

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

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/**/*"
    ]
}

Adam Rackis (@arackaf)

Adam Rackis (@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.

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

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

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.

Adam Rackis (@arackaf)

OP should be addressed by #18058.

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

Mohamed Hegazy (@mhegazy)

Mohamed Hegazy (@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

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

it should be in today's typescript@next.

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 :)

should be in 2.6, scheduled for October

Oh my - seems I missed 2.5! :D

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.

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

Wesley Wigham (@weswigham)

Wesley Wigham (@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.

Works for me too! Talk about instant gratification..

Navigation Menu

Repository navigation

`forceConsistentCasingInFileNames` does not always work with `paths` compiler option #17617

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

forceConsistentCasingInFileNames does not always work with paths compiler option #17617

Description

Activity

aluanhaddad commented on Aug 5, 2017

afshinm commented on Sep 3, 2017

arackaf commented on Sep 6, 2017

aluanhaddad commented on Sep 6, 2017

arackaf commented on Sep 7, 2017

aluanhaddad commented on Sep 7, 2017

arackaf commented on Sep 7, 2017

mhegazy commented on Sep 7, 2017

arackaf commented on Sep 7, 2017

mhegazy commented on Sep 7, 2017

arackaf commented on Sep 7, 2017

mhegazy commented on Sep 7, 2017

arackaf commented on Sep 8, 2017

jamietre commented on Feb 16, 2018

weswigham commented on Feb 16, 2018

aluanhaddad commented on Feb 16, 2018

jamietre commented on Feb 16, 2018

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

`forceConsistentCasingInFileNames` does not always work with `paths` compiler option #17617