Confiction with custom typescript plugins, monkey patching languageServiceHost.resolveModuleNameLiterals not work

[dyf19118]

Vue - Official extension or vue-tsc version

3.0.6

VSCode version

1.103.2

Vue version

3.5.18

TypeScript version

5.8.3

System Info

System:
    OS: Windows 11 10.0.22631
    CPU: (28) x64 Intel(R) Core(TM) i7-14700KF
    Memory: 17.98 GB / 31.84 GB
  Binaries:
    Node: 24.2.0 - C:\nvm4w\nodejs\node.EXE
    Yarn: 1.22.22 - ~\AppData\Roaming\npm\yarn.CMD
    npm: 11.3.0 - C:\nvm4w\nodejs\npm.CMD
    pnpm: 10.6.5 - ~\AppData\Roaming\npm\pnpm.CMD
  Browsers:
    Edge: Chromium (140.0.3485.54)
    Internet Explorer: 11.0.22621.3527

package.json dependencies

Steps to reproduce

reproduce steps are listed in the discussion: #5628

What is expected?

Monkey patching languageServiceHost.resolveModuleNameLiterals should work whether Vue official extension is enabled or not.

What is actually happening?

After Vue official extension enabled, module resolution of project files (non node_modules files) cannot be intercepted by monkey-patched languageServiceHost.resolveModuleNameLiterals in custom TS plugin anymore.

Link to minimal reproduction

discussion

Any additional comments?

No response

[dyf19118]

It may not be a bug or any problem related to Vue official extension. The ultimate goal is to have the control over how module requests are resolved (to have the ability to redirect some sort of module requests to different files, instead of what it should have been resolved to, by Standard Module Resolution Strategy).

[TalkativeGuy]

I second this. I have created a typescript plugin that resolves modules' paths in a slightly different way from what the default logic is. I have listed it in the plugins section in tsconfig.json and in the typescript.tsConfig.compilerOptions.plugins section in nuxt.config.ts.

It works perfectly well, until I try to make vue files with paths like those. In fact, it works fine in the Vue files too, but only right until I add a default import of a component, like so:

import MyComponent from "~/path/to/MyComponent.vue"

After that, all the paths that are invalid by the default TS logic (but are valid by the logic I have implemented in my typescript plugin!) are marked with the "Cannot find module" error.

Not only doesn't the custom resolution work, the plugin also doesnt output any messages regarding this file at all when there's an import of a component in it. Which means that the extension does block it completely for this file.

I have been trying for a long time to find the ways to "tell" the extension to use my plugin, but apparently there aren't any. Before, there was an option to create a volar.config.ts file, which seems to have had this exact function among others, but as far as I understand it is now suspended.

Other things I noticed:

• The "Cannot find module" errors disappear if I add or remove imports in another file
  • No effect from changing something else in other files or changing anything in the file where the error is
• The error is displayed back again when I edit the file where it was in any way

Seems like the extension just stops analyzing the file for a while on these occasions, enabling the plugin to handle the resolution. Until it doesn't.

Extension Version: 3.1.4

[TalkativeGuy]

I have also figured out that you can import a component through an index file like so:

import { MyComponent } from "~/path/to/index"

While there's ~/path/to/index/index.ts with this:

export { default as MyComponent} from "./MyComponent.vue"

And in this case, the plugin doesn't get blocked in the file and resolves all the paths. Which is pretty weird, because all the features which the extension provides (like syntax highlighting and typescript support for components' props) are still working, and the only difference I have found is that the plugin doesn't get blocked.

So, the single solution available is to make sure all your components are imported the way shown above. Not prefect for bigger projects where there's already lots of default imports used, but it is what it is. I have also tried to find an ESLint rule to disallow default imports of vue components in order to explicitly tell developers not to use them in the future, but I didn't find anything like this, so it will have to become a convention inside your project listed elsewhere. Also, I wouldn't be so sure that this will keep working in the future updates.

[KazariEX]

It works perfect on my local playground.

[KazariEX]

@TalkativeGuy Please provide a minimal reproduction for your case.

[TalkativeGuy]

@KazariEX thank you very much for the quick response! I've created a reproduction with a couple of examples. Here it is. There's a section "How the TS plugin is intended to work" in the readme file to let you better understand what's going on. I've tried to keep it as simple as I could. Feel free to ask any questions. Best regards.

[KazariEX]

It caused by https://github.com/volarjs/volar.js/blob/e08f2f449641e1c59686d3454d931a3c29ddd99c/packages/typescript/lib/node/decorateLanguageServiceHost.ts#L60-L89.

[TalkativeGuy]

@KazariEX Is there anything else I should do, and is there a chance for it to be fixed? Sorry, I'm not yet familiar with the workflow here.

[KazariEX]

We need to wait for @johnsoncodehk's opinion.

[dyf19118]

It works perfect on my local playground.

Monkey-patched getQuickInfoAtPosition works perfectly as expected ([🌏 region: ${region}] ), but the problem is module request to "./foo" will fail to be redirected to "./foo.bar". If you hover on (or cmd/ctrl + click) the "./foo", you will see the resolved file path is the path of the module "./foo" instead of "./foo.bar".