vue-tsc versionning and vscode-vue-languageservice dependency

[cexbrayat]

Currently vue-tsc specifies vscode-vue-languageservice as a dependency with version^0.27.0.

As vscode-vue-languageservice gets released pretty often, you can have different behaviors in 2 projects that installed vue-tsc@0.3.0 but at different times.

When vscode-vue-languageservice has a new interesting feature (or a regression), we can't easily install a specific version with NPM, as the one required by vue-tsc will be used (except in yarn projects where you can ask for a specific resolution).

Furthermore, tools like Renovate or Dependabot won't update vue-tsc until a new release is out, so you don't benefit from the new features of vscode-vue-languageservice until a new release of vue-tsc.

It could be interesting to either :

• release vue-tsc with the same version number than vscode-vue-languageservice, and with a fixed version dependency. For example vue-tsc@0.27.22 would have a dependency to vscode-vue-languageservice@0.27.22
• move vscode-vue-languageservice to a peer dep, so it could be specified in the project package.json, and set to a specific version easily.

[johnsoncodehk]

You can use resolutions to roll back version, see: https://github.com/johnsoncodehk/volar/discussions/402

• release vue-tsc with the same version number than vscode-vue-languageservice, and with a fixed version dependency. For example vue-tsc@0.27.22 would have a dependency to vscode-vue-languageservice@0.27.22

This is the most intuitive method, but it will cause github repos keep receive updates spam from vue-tsc.

• move vscode-vue-languageservice to a peer dep, so it could be specified in the project package.json, and set to a specific version easily.

Maybe use this way in the future. The only disadvantage is that if the user does not explicitly add vscode-vue-languageservice to the dependency, the package manager tool will report a warning.

[cexbrayat]

Thanks for your reply! The problem is that you can't use resolutions if you use npm and not yarn.

This is the most intuitive method, but it will cause github repos keep receive updates spam from vue-tsc.

Agreed. But I wouldn't mind keeping up-to-date, and tools like Renovate can be configured to slow the update pace for some packages https://docs.renovatebot.com/noise-reduction/#selective-scheduling (this works very well).

Maybe use this way in the future. The only disadvantage is that if the user does not explicitly add vscode-vue-languageservice to the dependency, the package manager tool will report a warning.

I agree as well. But this would be of great help when you need to upgrade or downgrade to a specific version, and you can't use resolutions.

Anyway, thanks for your work and for considering these options.

[johnsoncodehk]

This will process after refactored volar, because the dependency of vue-tsc may change from vscode-vue-languageservice to a smaller module.

[johnsoncodehk]

After considering this issue from all aspects, I decided to change to fixed version dependency. This way does not need to wait for volar refactored, so it will arrive in the next version v0.28.

This repo will be deprecated and move into volar monorepo.