I guess we're going so far as to supportfoo.d.tar.gz.ts? i.e. multiple dots?

Right now we interpret such a name as a declaration file, but will never match it, since we only consider everything after the last dot for the extracted extension. Somewhat on the fence about it right now tbh - I dunno if we need to handle compound extensions or not. Maybe I should adjust the lookup logic so it does?

I honestly have no clue. It seems like someone's going to try to do it... but maybe not?

Just as an FYI, all these extra watchers are here because these tests have an import that looks like"./tools/tools.interface" which now looks for a./tools/tools.d.interface.ts (for the potential literaltools.interface file) before adding a.js or.ts extension onto the import to find what it currently finds. The additional failed lookup location triggers adding a directory watcher, since now a new file may appear which changes the resolution result~

can you instead change the test to import "./tools/toolsInterface" since the extension part is irrelevant for these tests?

It is probably worth noting that while these types refering to a ts source file in the import do now resolve, the error on the import is still present - it's just added in the checker even on successful resolution now.

Doesn’t this falsely trigger onimport {} from "./foo.ts" when the source file isfoo.ts.ts? In my implementation, I couldn’t find a better way than to add a property ontoResolvedModule that indicated whether the.ts extension was actually used to match a.ts file extension.

The error says that the "import path can't end in.ts" not that it can'tresolve to TS, so I'd argue it's not a false positive. Honestly, a"./foo.ts" that resolves to"./foo.ts.js" is expempted from the error right now, but I'm questioning more ifthat's OK - blanket saying "relative import specifiers can't end in .ts unless you pass some flag" just seems easier to understand, and covers weird cjs corners like this, if overzealously.

can you instead change the test to import "./tools/toolsInterface" since the extension part is irrelevant for these tests?

These checks seem non intuitive. When types or exports entry already has "d.ts" extension and we are saying we prefer ".ts" over ".d.ts" even though field said to use ".d.ts" .. Just more configuration error prone i think.

This is generally true all the time -.ts files that correspond to a.d.ts file are higher priority than the.d.ts file, even if your path explicitly uses the.d.ts extension. This is basically to mirror our wildcard include behavior which likewise prefers the.ts file to the.d.ts file.

Are filenames like this problematic now?

No, they just add a (higher priority) lookup location which has knock-on effects regarding file watchers in the baseline, so to avoid baseline noise Sheetal asked I simply change the filename.

I was gathering module-resolution-affecting compiler options for docs, and noticed this. AFAICT it doesn’t affect module resolution, just whether an error is issued. This should probably be swapped foraffectsSemanticDiagnostics.

Is this something that should be in 5.0 beta? I just got to this comment in my email and noticed a PR wasn't sent for this (but I don't know how these two settings matter myself)