importModuleSpecifierEnding is not supported in Take Over mode

[sheremet-va]

We are trying to move our code base to moduleResolution: "bundler", but auto import keeps importing files without the extension. I found a solution to enable javascript.preferences.importModuleSpecifierEnding: "js" flag, but it seems that it is ignored, if Take Over mode is enabled (the setting is grayed out in settings.json).

If I disable Take Over mode, auto importing appends .ts extension to our imports.

[sheremet-va]

Reproduction: https://github.com/sheremet-va/volar-bug-extension

@johnsoncodehk Would really appreciate your input here 🙏🏻 I noticed that without the take over mode, it works, but inside Vue files the extension is .js, but when importing inside .ts files the extension is .ts.

[johnsoncodehk]

Thanks for the repro case, but I can't reproduce the problem, Volar behavior is consistent with takeover mode disabled behavior to me.

@johnsoncodehk Would really appreciate your input here 🙏🏻 I noticed that without the takeover mode, it works, but inside Vue files the extension is .js, but when importing inside .ts files the extension is .ts.

It's also consistent behavior, you can try to execute Volar (Debug): Write Virtual Files command, the src/components/Cmp.vue.ts virtual will be created to the workspace, and then you can test auto import in Cmp.vue.ts, the import of #mobile/utils is ending with .js.

[sheremet-va]

Thanks for the repro case, but I can't reproduce the problem, Volar behavior is consistent with takeover mode disabled behavior to me.

The issue is changed a little bit since the last report, but I can still reproduce it. .js extension is always used in Vue file, but typescript files use .ts extension when auto imporing. Enable these in your config file:

  "javascript.preferences.importModuleSpecifierEnding": "js",
  "typescript.preferences.importModuleSpecifierEnding": "js",

Volar plugin is installed. TypeScript Vue Plugin doesn't change the behavior anymore.

I also moved the base file to components to better illustrate the difference.

Try to auto import getName in components/base. It will be autoimported like this (with .ts extension):

import { getName } from '#mobile/utils.ts';

Then try to auto import getName in components/Cmp.vue (notice it has lang="ts"). It will be auto imported like this (with .js extension):

import { getName } from '#mobile/utils.js';

Screen.Recording.2023-04-15.at.13.27.19.mov

It's also consistent behavior, you can try to execute Volar (Debug): Write Virtual Files command

This is also not true for me. When auto importing "Cmp" it uses .ts extension (try this in a new components/base.ts file. As a user, it is weird to me that I can import the same file, but it will have a different extension depending on the current file. So this is definitely not consistent.

Screen.Recording.2023-04-15.at.13.24.46.mov

[johnsoncodehk]

It should be fixed by f786efa, thanks.

[sheremet-va]

Thank you for the fix! It does seem to work now (also the import happens on the first line and not in the "<script>" part, which is nice).

But with v1.3.18 I noticed that when pressing "Cmd+." in Vue files to autoimport it, VS Code shows me "No actions available". But it works fine in TS files.

The reproduction is the same.

[johnsoncodehk]

Unfortunately code actions is now disabled by default: #2620

[sheremet-va]

Unfortunately code actions is now disabled by default: #2620

From the description you gave in the PR, it seems that not all code actions should be disabled. Only for auto fixing and stuff, no? This sounds more like punishing people who understand the reasons for ESLint slowness. I personally don't have any auto fixers, so this issue doesn't affect me for a few years now.

I think this change will only cause new issues in the realm of "why doesn't this work" and a new wave of people who need explaining which defeats its original purpose.

[johnsoncodehk]

I complain a bit, but that's not to punish users. Users can actually set any code action kind other than "source.fixAll" / "source.organizeImports" in codeActionOnSave, such as "quickfix", so only disabling some code action kinds will not completely avoid the problem.

I also considered disabling code actions only if the user has ESLint installed, but that seems to be over design.

[sheremet-va]

Users can actually set any code action kind other than "source.fixAll" / "source.organizeImports" in codeActionOnSave, such as "quickfix", so only disabling some code action kinds will not completely avoid the problem.

Should we just disable running code actions on save by default then? The fact that I cannot import the variable with Cmd+. feels like it was not intended by this change.

[johnsoncodehk]

We could read the codeActionOnSave setting to do this, but I think this would confuse users as it seems that certain codeActions are randomly disabled in different projects. Enable / disable all uniformly is a trade-off.

The closest solution is to judge the trigger kind on the language server to ignore the code action on save request, but there is still a problem. When saving is stuck, this will not prevent VSCode from displaying that Volar is executing code action.

[johnsoncodehk]

I came up with another solution in d629d76, now code actions are enabled by default, and automatically disabled when the saving time is too long (default 500ms), so we don't have to care about the reason behind it or what extensions the user installed.