Files with the same name (without extensions) are not parsable #955
Comments
|
This is because of TS diagnostic 5056 - Perhaps we should whitelist this diagnostic? We're not writing files, so we don't care if they would overwrite one another. |
|
Digging into this a little bit - it's not a diagnostic that's being thrown that stops this from working. It looks like the Watch Compiler Host we create via Logging out of See: #957 |
|
Digging into this more via the debugger.
This is the code which does the check: Copying the relevant source code comment here because the file's too long for github's preview system: This system also works "retroactively" so that it will stop tracking a So in order to handle this, we'd have to build a system to detect this case, and then create a separate program for this duplicate file. Which I think is probably way too much effort for an edge case? cc @uniqueiniquity as an FYI |
|
Yeah, that does sound like quite a bit of work. Thanks for looking into this and nice job debugging it 💯 I would suggest maybe filing an issue with |
|
This is interesting - I just came across this myself. I was trying to do: And became very confused when this resulted in This can't be that unusual of a usecase, right? |
|
It is uncommon because it doesn't actually work in practice. If you define the above, and then do: When you do a build, what should typescript output? If you do The answer is that it uses the ordering mentioned above to pick a file. With declaration files on, I just did some testing to verify all of this. Typescript doesn't explicitly error on the file like we do, but it doesn't work either. Unless I'm missing something about the use case, that is. I'd love to know more about why you want to do this. |
|
@bradzacher thanks for your thoughtful response!
There really isn't an important usecase in my case :) I think ultimately my motivation for wanting this is just that it "feels right" to have an entry point (index) file for my production code and my types. Particularly if I'm organizing my directory structure by component.
Well, in this case I could see the compiler failing with a message that warns you about the ambiguous import. I feel like it should be fixable by specifying the file extension in your import, though. |
|
Yeah typescript acts without a clear error message here, unfortunately. We could potentially improve the error messaging on our end, but it'd come at a perf cost for the error case, as the only way to tell if typescript has done this is by doing a filesystem lookup when the ts program returns nothing to us. On one hand, if someone's setup is particularly bad it could slam the hard disk with activity and add a lot of runtime. Undecided if it's a good idea, or if we just rely on documentation in the readme. |
Moving this out of #890 as it's an issue we need to track.
Comment by @toddbluhm:
The issue appears to occur when I have two files with the same name (
fixture.ts&fixture.js) in the same folder (src). It only picks up the.tsfile and will not pick up the.jsfile. Instead, it gives the error thatfixture.jswas not included in the project.**tsconfig.json**
{ "extends": "./node_modules/tsconfigs/universal", "compilerOptions": { "esModuleInterop": true, "importHelpers": false } }**tsconfig.eslint.json**
{ "extends": "./tsconfig.json", "compilerOptions": { "allowJs": true, "checkJs": true }, "include": [ "src/**/*", "*.ts", "*.js" ] }**.eslintrc.json**
{ "extends": "./lib/index.js", "parserOptions": { "project": "./tsconfig.eslint.json" } }**Example file paths that are throwing errors**
/Users/toddbluhm/Development/Github/eslint-config-standard-with-typescript/src/fixture.jsThe file does not match your project config: /Users/toddbluhm/Development/Github/eslint-config-standard-with-typescript/src/fixture.js.
The file must be included in at least one of the projects provided
Versions
@typescript-eslint/eslint-plugin2.0.0&2.0.1-alpha.27@typescript-eslint/parser2.0.0&2.0.1-alpha.27TypeScript3.5.3node10.15.0The text was updated successfully, but these errors were encountered: