fix: also respect compilerOptions.moduleResolution for ending preferences

[JoshuaKGoldberg]

The root issue was that TypeScript only looks for user preferences or a package.json "type": "module" when determining whether to add .js to extensions. Some projects don't have either of those set, but still use "compilerOptions": "node16" or similar in their TSConfig.

Fixes #52886

[JoshuaKGoldberg]

Lint failures will be fixed by #53243.

[Andarist]

@JoshuaKGoldberg that PR landed shortly after you opened this one, you can sync with main to resolve the issue :)

[andrewbranch]

--moduleResolution nodenext doesn’t mean that extensions are required; it just means that extensions are required in ESM files. What you have in your test are CJS files, where extensions are not required. The refactor should infer from the existing code that extensions are preferred, but it’s incorrect to infer that preference purely based on the module resolution setting. I’m not sure what the issue is in #53244, but most likely the refactor isn’t passing the resolutionMode correctly.

[JoshuaKGoldberg]

TIL, thanks for the explanation!

The refactor should infer from the existing code that extensions are preferred

Interesting - looks from 3505fb9 that TypeScript already is.

most likely the refactor isn’t passing the resolutionMode correctly

Hmm, looking through the SourceFile type it looks like impliedNodeFormat?: ResolutionMode is parsed & set separately from the refactor. So maybe the issue is no longer valid, and since fixed? I can't reproduce bad behavior in the test cases...

infer that preference purely based on the module resolution setting

Edit: actually, I'm confused - why is this not the case? I thought with moduleResolution: "bundler", it would be expected that Node16/Nodenext compiler options are expected to be .js?

[andrewbranch]

Looks like the bug was a duplicate of #50710 and already fixed by #51702.

Edit: actually, I'm confused - why is this not the case? I thought with moduleResolution: "bundler", it would be expected that Node16/Nodenext compiler options are expected to be .js?

I’m confused about what you’re confused about 😆 bundler didn’t change anything about node16/nodenext. Module resolution strategies that support extensionless paths include:

• Node require
• Most bundlers and non-Node runtimes (even in import)

In these scenarios, you’re allowed to have an aesthetic preference as to whether you include file extensions on your relative module specifiers, since they work either way. This is what the VS Code preference controls (and what we’ll try to infer from existing usage).

In Node ESM imports, you’re not allowed to omit extensions, so the preference doesn’t come into play. You just have to have extensions, no matter what the VS Code preference says, and if auto-imports or whatever fails to add it, that’s a bug.

Does that clear things up?

[JoshuaKGoldberg]

Got it, thanks - that's very helpful!