Extension-less imports don't work in TS Plugin Mode

[machty]

In classic/deprecated Language Server mode, we support using extension-less import module specifiers, e.g.

import Greeting from './Greeting';

In new TS Plugin mode, it fails to resolve the import until/unless you change to:

import Greeting from './Greeting.gts';

Example in our codebase:

https://github.com/typed-ember/glint/blob/main/packages/vscode/__fixtures__/template-imports-app-ts-plugin/src/index.gts#L7

Perhaps this isn't fixable

I'm waiting back to hear whether this can be fixed in Volar, but it's possible there is no solution to this, in which case apps that want to use new Glint in TS Plugin mode will have to codemod their imports to include extensions.

[bertdeblock]

Running into this issue as well, however, explicitly defining the .gts extension results in a runtime error for us (classic / non-embroider build).

[machty]

@bertdeblock what runtime error do you encounter?

[NullVoxPopuli]

classic build doesn't resolve extensions, because it goes through requirejs, which has already removed the extensions, so it'd probably be "module not found" or similar

[bertdeblock]

Yes, correct.

[machty]

Sounds like our options are:

1. Babel transform or some other config/hack to get extension'd import module specifiers working correctly in classic build
2. Upstream Volar fix (if one is even possible given tsserver/ts plugin constraints)
3. Perhaps apps that want the latest Glint should run the embroider codemod that was recently released (with support back to 3.28)?

[NullVoxPopuli]

1 & 3 seem the most feasible to me -- 2 continues encouraging implicit extensions, which I don't think folks want, broadly.

The babel plugin would be the easiest of the 3 options, and would be most quickly unblocking. ChatGPT could maybe even do it. haha

[NullVoxPopuli]

https://astexplorer.net/#/gist/9713c4f3066919ad044881afebb64b58/ca4323716244e01df6618ba77da47f96957679ab

[bertdeblock]

Something else I noticed:

None of these are found, which is what this issue is about of course.

But if I add the .gts extension to only one path:

The others are found as well, and type checking seems to work as expected.

[machty]

Very weird; if you "Go to Definition" on NoResultsPlaceholder in the 2nd screenshot, does it go to the right file?

[bertdeblock]

@machty yup, it goes to the right file.

[machty]

@bertdeblock and in the first screenshot (if you remove the initial .gts) does "Go to Definition" work on NoResultsPlaceholder ?

[bertdeblock]

Nope, than VS Code just jumps to the first location where NoResultsPlaceholder is used within the same file.
It seems like, once .gts is used somewhere in the file, it's used as a fallback for other import paths?

[bertdeblock]

@machty Could it be that we need to implement the same hack for .ts files as well?

For example:

rich-text-editor is a .gts file being imported in a .ts file, but Glint/TS cannot seem to find the module.