[RFC] Volar feels broken beyond repair on VSCode

[michealroberts]

Introduction

Firstly, I would like to state that Volar has been a great tool over the years, one that I have been very grateful for and I am very grateful for @johnsoncodehk for all the work he, as well as the contributors and maintainers have put in.

This is not an easy write.

Apology

I am sorry for what I am about to write, and apologise if this breaks any of the community guidelines in any way.

I wouldn't be writing this if Volar was still a community led package.

Issues / Pain

Working with Volar over the past two months in VSCode has left A LOT of lost and frustrated hours debugging various intellisense and "any" issues around various codebases I work on. I am at breaking point with Volar.

The severity for me has hit breaking point. For the first time in 8 years I am no longer feeling confident or comfortable to continue to build new projects in Vue 3.

The issues are just seeming to compound on every release, and with every VSCode release. I am no longer building things, I am debugging VSCode, restarting servers, typescript engines, Vue servers just to try and get things to work.

I often look at the pains points, and look to open an Issue, then back down feeling like I will never be able to reproduce the issue or even understand how to provide a decent reproduction. It just feels like without reproductions, the team won't know how to debug any of these issue.

There are massive performance issues on save of *.vue files, the intellisense is, for the most part, broken in large projects and monorepos. My .vue files are littered with "anys" and when I check their types upstream, they are typed correctly.

I have shelved building a new project in Vue 3 because of these issues, and am looking to solid or svelte as antidotes. (I'm sure I will come crawling back, tail between legs).

Solutions:

As most people use Volar via VSCode, I feel like the Volar team needs to reach out with Microsoft (if this hasn't already been done) and book some time with them to work through issues and debug performance bottlenecks with both VSCode and Volar. The lack of intellisense on larger projects and the save times really needs addressing urgently.

The team should look to test Volar on a real-world large enterprise projects (the pain I have found has been around monorepos), I am not confident that the team tests performance on anything more than the Vite / Vue starter templates, if at all. (Please correct me if this is wrong or incorrect).

Are there any alternatives to Volar at this point? Is anything being cooked up? Volar version 2?

Summon Evan

I need @yyx990803 to read this, as I feel like the Vue core team need to supply some antidotes to this rant and hopefully provide support to @johnsoncodehk.

[so1ve]

You have mentioned various kinds of issues in your write-up:

1. Components are typed as "any"
2. No intellisence in monorepo
3. Poor performance when saving

IMO they should be fixed in the latest release. If you are sure they are not caused by your project config, please create a new issue with a minimum reproduction.

In addition, pinging author directly is rude. Johnson is working on volar.js recent days, which powers Vue language tools. Please be patient, at least.

[michealroberts]

@so1ve Thank you for your comment but I strongly feel that the exhaustion felt by a lot in the community can not longer be over-looked, hence why this was directly addressed to the package maintainers. This is more an RFC for how this package moves forward and a dialog between the core team and the community rather than the usual "can you produce a minimal reproduction".

Let's stick to a discussion on solutions and what is needed to stabilize this tool moving forward for a large number in the Vue community. 🙏

[johnsoncodehk]

It would be great if you can provide a repro case, even if it's not minimal. I'm curious if we can't reproduce your problem, what do you think we can do to solve it?

I'm equally helpless with save performance issues, usually disabling editor.codeActionsOnSave / disabling ESLint will fix the problem, which proves that the problem is not from Volar, but everyone is just ranting. If the problem is so serious, why do people insist on enabling editor.codeActionsOnSave and continue to rant about Volar?

I have never overlooked any issues as long as the reporter is willing to help resolve them. But I have a lot of other related work on hand, so I can't deal with issues in a short time.

In the end, I am just one of the users of Vue. I originally made this project to solve my own problems. Now the things in this repo have long been out of my interest. I continue to maintain it out of goodwill to help others rather than an obligation. I don't ask people to pay me for my work, but I do get tired of people's constant demands, and to be fair I wish I'd seen more PRs / repro cases than rants.

[matthew-dean]

I'm equally helpless with save performance issues, usually disabling editor.codeActionsOnSave / disabling ESLint will fix the problem, which proves that the problem is not from Volar

I disagree. I think there's some intersection of Volar + ESLint at work here (or ESLint + the Vue plugin? 🤷 ). That is, in my experience, ESLint is only extremely slow at running actions on save when it's in a .vue context.

[michealroberts]

Hi Johnson, thank you for your reply. It's by no means a rant from my side. I'm very calm and considered in my wording - it has been several months where it has got to a point where I needed to be brutally honest. This is more directed at the Vue project as a whole, and to say that a lot of developers are now struggling to work with Vue 3 because of the tooling. And to raise that using Volar has become a serious pain point. But at the moment there is no alternative, so it feels like we're in a precarious position as developers.

It's clear the project needs more focus from the Vue core team and wider community and on Vue itself, and for some of the community efforts mentioned in the solutions I spoke of. It's been 6 months since a new beginning was announced, we assumed you were now being paid for this work and had dedicated authority to take it forward with the support of the core team. Is this still the case?

The issue is for us as developers, is that this isn't a community core package anymore, and has been adopted as part of the core DX tooling for Vue 3. I guess that is the risks of open source. It worries me that you're not getting the support needed by the sounds of things. We made the switch from Vetur to Volar and with great promise. But it seems to be that Volar, with other tools attached (such as formattingOnSave / eslint / the typescript engine etc etc), falters quite dramatically for monorepos and larger enterprise projects.

I knew I had to say something when the usually impeccable DX for Vue was faltering to the point where I was considering using react going forward!

All joking aside, my initial post was to raise just how serious I feel this issue is and to focus on solutions. I am also happy to be proven wrong and have someone far more knowledgeable on this than me look over my monorepo repository and see if replications can be made and fixes proposed. I always feel bad offering a larger reproduction like this because it ends up that we feel like you're doing our work for us, for free.

Maybe we could initialise, with the core team's help, a state of the union survey, Volar pain points and then start reaching out to the VSCode team?

[matthew-dean]

I feel like your title / original post is a little hyperbolic because Volar is by no means "beyond repair". Yes, it's extremely buggy, and I usually have to restart the Volar server maybe 20+ times a day. Yes, formatting on save takes a minute plus sometimes. Buuuut when Volar is working, it works really well, and having proper typing in Vue templates is a huge time-saver.

That said, I think you do make an essential point that a reactive library is, in reality, only as good as its tooling. Vue could be best-in-class in syntax and performance, and all of that is moot for modern frontend teams if the tooling is not reliable. There's just too much to do, far too quickly, to try to debug the essential underpinnings of a library.

Case in point, I'm dealing with a very old Knockout codebase. Knockout syntax is probably not the worst I've seen... in some ways there are some parallels to Vue. But without tooling support, debugging when there's a problem takes forever, as it's all only debuggable at runtime, and a runtime error may not occur immediately depending on the code path. It's super-painful.

Volar has a lot of promise, but yes, it does still feel like an alpha or pre-alpha product. I do hope that something can be done to stabilize it moving forward, as the company I'm working for has a lot of buy-in on Vue.