GeezerVison

What we really need, and I’m not sure whether we have (but we might), is a function that maps input file extensions to emitted file extensions. So we would have

• .ts → .js
• .tsx → ? (I don’t know if this is always .js or if we might emit .jsx with --jsx=preserve?)
• .mts → .mjs (someday soon)
• .d.ts → undefined because it doesn’t get emitted
• .json → .json (only if --resolveJsonModule?)
• .js → .js

If we don’t have that function, we need to (a) figure out what the right thing for TSX is and implement it now, and (b) remember to update it for .mts and .cts if/when we add those.

Emitter.ts has getOutputExtension which does approximately that, but it works on a sourceFile. Since we're just working working with the paths here we probably just want a new similar function that handle the cases we need.

👍 in absence of something better, just leave comments on each function (getOutputExtension and the new function) saying to keep them in sync with each other.

Found it:

I would maybe just export that function so it doesn’t immediately cause merge conflicts with #44501.

Actually, you might need to refactor it to return undefined instead of throwing on unsupported extensions, and move the debug assertions to its caller, or another wrapped version of it. But otherwise I think this function is exactly the thing we were looking for.

To me this one sounds like the one that never throws. I would suggest naming the undefined-returning one tryGetJSExtensionForFile and the throwing one getJSExtensionForFile.

I thought it was sketchy that this function didn’t have undefined in its return type, so I looked and found that it too has an undefined-returning counterpart, and this one throws! This may need to be swapped for tryGetExtensionFromPath for good measure. This also makes me realize we should have a test that actually returns completions for a non-source-file file extension, like index.css or something.

I don't think we even read other extension types from disk, but I think you mean something like

//@filename: index.css
body {}

//@filename: index.html
<!DOCTYPE html>

//@filename: foo.ts
import "./

And expect nothing at the uncompleted string?

Hm, I looked at stringCompletions and saw tryReadDirectory, so I assumed we were offering everything we could find, with extension substitutions as appropriate. Not sure what’s going on then 🤔

You could certainly be seeing an artifact of the fourslash client 😬. Have you checked the behavior against a Real Editor?

I was pretty sure that tryReadDirectory only returned files that matched its extensions argument, if provided. I might be misreading though.

either way, updated to not use the throwing variant :)

Ah, I missed that parameter 🤦‍♂️

It might actually be nice to allow all extensions here in the future, since we can no longer seriously claim to believe we’re in a world where people only import things we know how to analyze. This doesn’t even account for declare module "*.css" pattern ambient module declarations. But that’s for another day. Thanks!

Oh geez TIL. Is that a wildcard module declaration?