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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem with "File name ... differs from already included file name ... only in casing" #50569

Closed
akphi opened this issue Aug 31, 2022 · 6 comments
Labels
Duplicate An existing issue was already created

Comments

@akphi
Copy link

akphi commented Aug 31, 2022

Bug Report

馃攷 Search Terms

File differs from already included file only in casing, only in casing, File differs

馃晽 Version & Regression Information

This changed between version 4.7.4 and 4.8.2. I tested with 4.8.1-rc and it still works fine, so maybe something happened in 4.8.2

馃捇 Code

This is my repro branch
akphi/issue-repo#9

If I have to speculate, the particular thing about my setup is I use module: NodeNext and forceConsistentCasingInFileNames: true and in src folder, I have 2 files: (1) imports something from a library package (e.g. serializr) and (2) imports something from a package that has serializr as a dependency) (note that I already tested with other packages to make sure it doesn't only happen toserilizr).
(2) imports from @finos/legend-shared, a package that ships ESM code. Really sorry about this complexity in the setup, I have tried my best to reduce the size of the repro 馃檹. But this is crucial for our setup: basically, we have a codebase that publishes @finos/legend-shared - an utility only library and consume that in another codebase, hence when I bump into this error

To reproduce the issue, run the following:

npm install && npm run dev:ts

馃檨 Actual behavior

I got the error

src/index.ts:1:27 - error TS1149: File name '/Users/my-user/Developer/js/issue-repo/node_modules/serializr/lib/serializr.d.ts' differs from already included file name '/users/my-user/developer/js/issue-repo/node_modules/serializr/lib/serializr.d.ts' only in casing.
  The file is in the program because:
    Imported via 'serializr' from file '/users/my-user/developer/js/issue-repo/node_modules/@finos/legend-shared/lib/application/SerializationUtils.d.ts' with packageId 'serializr/lib/serializr.d.ts@2.0.5'
    Imported via "./serializr" from file '/users/my-user/developer/js/issue-repo/node_modules/serializr/lib/constants.d.ts' with packageId 'serializr/lib/serializr.d.ts@2.0.5'
    Imported via "serializr" from file '/Users/my-user/Developer/js/issue-repo/src/index.ts' with packageId 'serializr/lib/serializr.d.ts@2.0.5'
  File is CommonJS module because '/users/my-user/developer/js/issue-repo/node_modules/serializr/package.json' does not have field "type"

1 import { serialize } from "serializr";
                            ~~~~~~~~~~~

As you can see in my src/index.ts file

import { serialize } from "serializr";
export { default as hashObject } from "object-hash";
import { cloneDeep } from "lodash-es";

This also fails for object-hash and lodash-es.

馃檪 Expected behavior

This should compile fine.

@fatcerberus
Copy link

Looks like a duplicate of #50544

@MartinJohns
Copy link
Contributor

MartinJohns commented Aug 31, 2022

Duplicate of #50544.

edit: Oh wow, wisdomcerberus was a split second faster. :-D

@akphi
Copy link
Author

akphi commented Aug 31, 2022

Just to point out a small difference, I looked at #50544 they claim this doesn't work for all versions they tried, I only see this manifesting post 4.8.1-rc

@MartinJohns
Copy link
Contributor

they claim this doesn't work for all versions they tried, I only see this manifesting post 4.8.1-rc

It's part of the issue template, and too many people don't fill it out correctly. It's safe to assume they just tried a single version.

@RyanCavanaugh RyanCavanaugh added the Duplicate An existing issue was already created label Aug 31, 2022
@alecmev
Copy link

alecmev commented Aug 31, 2022

Sorry, indeed, I didn't test on earlier versions, assumed it was present in all relevant versions because it coincided with us enabling moduleResolution: Node16, but looks like it's a recent regression after all.

@akphi
Copy link
Author

akphi commented Sep 1, 2022

Closing this as #50557 has been merged. Thanks @sheetalkamat !

@akphi akphi closed this as completed Sep 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Duplicate An existing issue was already created
Projects
None yet
Development

No branches or pull requests

5 participants