Vetur 1.0 Roadmap
octref opened this issue · comments
Synopsis
A lot of work lies ahead to get Vetur to 1.0. This roadmap exists to:
- Give a big picture as to what's left.
- Inform the complexity of the remaining issues.
- Inform the prioritization of features/bug-fixes.
- Guide you to the correct issues to follow up.
This issue is a live document updated frequently.
This issue supersedes #188.
Signage
- 🌟 Current focus.
- 🏃♂️ In progress.
- 🚨 Upstream issue or support needed.
- ☑️: Features implemented.
Discussion in This Issue
Please make the discussion stay high-level.
Good Discussion: 👍
- I think this feature area is missing, and it's important because...
- If you have xxx, it would make it much easier for people to contribute...
Bad Discussion: 👎
- When can you support pug formatting? (Complain in individual issues).
- How do I configure Vetur to do xxx? (Open new issues for questions).
Features
Here is how Vetur looks like from each feature area. In each section, I describe:
- Current state
- What's missing
- Complexity of the features
This section provides a high-level overview and omits smaller bugs.
Vote for areas that you want more support:
🌟 Smart Editing in Template Interpolations
In Vue file's <template> region, you can use interpolations. For example, in this snippet:
<div v-if="this.foo">{{ this.bar }}</div>both this.foo and this.bar are template interpolations. Currently, Vetur has no smart editing support for them, including:
- 🌟 🏃♂️ Diagnostics / Type-Checking. #681 and #209.
- 🌟 Autocompletion
- Hover information
- Jump to definition
- Find References
- Rename Symbol
Full support for interpolations requires a new dedicated Language Service. Some ground-work (#802, #800, #786) was done to make this Language Service testable, maintainable and able to serve as the basis for implementing all language features.
Complexity lies in
- Vue's interpolation could include filter which is not standard JavaScript.
- Properties on
thisare bound to global scope. For example, instead of<div v-if="this.foo">, you can do<div v-if="foo">.
Multi-root and Sub-folder support
Currently, Vetur provides no multi-root support. Also, if your Vue project is not on the top-level, Vetur will not activate. The current plan is to make Vetur activate on each folder of a multi-root setup, if a folder contains a package.json. Instead of supporting sub-folders such as /client/, we'll advise people to open both / and /client so Vetur could work on the subfolder.
JSX Support
We have no support for JSX yet. This should be implemented as a TypeScript plugin, same as lit-html.
Issues:
- 🚨 Syntax Highlighting for JSX. #49. Blocked by microsoft/vscode#44056.
- Emmet in JSX. #693.
TypeScript Plugin Support
TS Plugin allows us to take control of editing experience for JS/TS files. This is required for rename support, so that you can run renaming on a JS file and see all <script> regions in Vue files getting updated.
Vetur would need to setup a TS Plugin and bi-directional communication between Vue-Language-Server and it. There's a lot of uncertainty and complexity involved.
This could also lift the limitation that you need to add .vue suffix when importing Vue files from JS/TS.
Upstream TypeScript features
A lot of new TS smart-editing features have come to VS Code. Some of them benefit Vetur directly, others would need manual integration:
- Auto-import in
<script>region. #684. - Organize import. #843.
- Refactor support. #871.
- Update import path when moving file. #820
In addition to bringing these features to Vetur's support for <script> region, we can also think about what more we can do in the context of .vue files. For example, refactor support for <template> that would extract a sub-tree into a new component.
Integration with other tools
Vetur already has integration with emmet | prettier | prettier-eslint | eslint-plugin-vue, and framework integration with many Vue-based frameworks. Issues for those are tracked in integration:<tool> labels.
What's missing are:
- TSLint integration. #170.
- Use locally installed dependencies for
prettier. #523. - Prettier as template formatter. #950.
Hopefully, we can also reach a spec for describing Vue components (similar to dts files) that would make it easy to:
- Generate definition files from .vue source files.
- Read from those definition files in Vetur for various smart-editing features.
Related: vuejs/vue#7186
Stability / Performance
Vetur has been stable and performant enough for most people to use daily. However, there are a few perf-related issues we need to fix:
- Vetur Intellisense slow and incomplete if project has jsconfig. #547.
Missing Tooling Libraries
Vetur brings in many tooling libraries and try to make them working harmoniously in .vue files, such as vscode-css-languageservice, prettier and language-stylus. However, we don't have the following tooling libraries:
- A good HTML formatter: prettyhtml by @StarpTech ~~~(Prettier is working on it (prettier/prettier#4753), but I guess it wouldn't directly apply to .vue files, especially for interpolations).~~~ Related: #491, #561.
- Pug Language Service.
- Sass Language Service.
- PostCSS Language Service (mostly covered by
vscode-css-languageservice, but newer features in CSS aren't covered).
I wouldn't have time to work on any of these as of now, so features in this areas are blocked.
Contribution
This is a daunting todo list. I would very much love contributions!
There are many ways you could contribute. Two major ways:
- Contribute to building one of the "Missing Tooling Libraries" above. For example, #561.
- Contribute to Vetur itself. This would be complicated if you've never done any Language Server development now. I plan to make that easier by:
If you do want to take major features, please open issue to discuss about it early. Otherwise, you might do a lot of unnecessary work by going to the wrong direction.
Rip html formatting
js-beautify is finally fixing a bunch of bugs, so I'll bring it back when 1.8 is released. Prettier support for Vue is probably gonna take much longer.
Edit: prettyhtml support is added via #912. So far it works great for me. Y'all should thanks @StarpTech's hard work!
There is no option to fold the code.
Remote editing (opening files on a network drive) causes the vue language server to crash repeatedly. Adding remote editing support would be appreciated as I work off of network drives frequently and vetur is unusable for me.
@ericettensohn Please open another issue with more details on your remote editing setup. I don't think it's necessary for 1.0 release though.
Has any progress been made on multi-root support?
If not, can I help? Maybe someone could point me in the right direction in the codebase, and I can get that taken care of.
Has any progress been made on multi-root support?
If not, can I help? Maybe someone could point me in the right direction in the codebase, and I can get that taken care of.
@dacarley
Can't help you with the codebase, but FYI, the Issue is funded on Issuehunt. https://issuehunt.io/r/vuejs/vetur/issues/815
is there any plan for mixin support?
Cost me a day of hair-pulling before I found this issue. I'm in a monorepo and yes, when I opened the Vue app's folder directly in VS Code, now it can find my @/... modules in .vue files. Hope this will be fixed soon!
@octref disregard that request, sorry. I saw the fix posted here of mapping the share to a drive letter and adding it to the workspace and that worked fine. Thanks!
@ericettensohn If you're working over network shares you may also be interested in issue #1758.
It would be great, if there is option for "Go to definition" for vue component.
Where cursor is on vue component and we press F12 or "Go to definition" it can open that particular vue component.
Currently we have to search that import and look into path and then search that component in vs code and click it to open it.
Can't these steps be made in single steps?
@hnviradiya I believe your request is related to #1712. I've made a PR to support this. Hope it would not raise other issues and got merged soon.
Would you be kind enough to test this PR and let me know if it completes it's mission ?
@hikerpig awesome. i just couldnt find this.
still waiting for support for multiple roots.
Monorepo is becoming quite popular, and Vetur does not support it.
@Minigugus Sorry, I'm not unaware of it, just doing other PR/changes first since multiroot/sub-folder support will be a larger change, so it's better to get smaller PRs in first. I'll need to spend more time doing performance testing, making sure existing single-root based features won't break (such as snippet, Component Data support), and spending multiple days after releasing it to handle all kinds of bug reports.
Another thing is I need to prioritize some work for the upcoming Vue 3 release.
@octref Ok, thanks for that quick response.
I'll need to spend more time doing performance testing, making sure existing single-root based features won't break
According to the architecture of the solution, there should be no breakable changes for existing projects, since the behavior of the fixed code is the same in this case (only one pair of LanguageService is created). However, I think that if new bugs occur, they will, for the most part, be related to the alternatives currently in place rather than to broken features (especially for projects currently using several tsconfigs but which don't work properly).
I'll need to spend more time doing performance testing
What can I do to make it easier for you?
Another thing is I need to prioritize some work for the upcoming Vue 3 release.
Maybe we can help (with a vue3 label for instance?) 😉
Shall we have the new feature behind some config (like vetur.experimental.nonTopLevelProject), so that we could not worry about possible breaking changes and/or performance decrease?
Could we change the the TSLint target to Eslint + Typescript? TSLint is deprecated, and ESLint now provides built-in formatter eslint.format.enable to be able to replace or provide alternative to prettier-eslint. See #170 thread.
I'd like to try and work on this, or help if I can. On a side note, would you mind if I submit a PR for changing the project to use ESLint + Typescript and removing prettier and TSLint? (Just wanted to mention I was able to replicate all Prettier and TSLint config with just ESLint at https://github.com/josh-hemphill/vetur/tree/pure-eslint)
I'd like to try and work on this, or help if I can.
I think that's what more people would need. You are welcome to send a PR 👍
On a side note, would you mind if I submit a PR for changing the project to use ESLint + Typescript and removing prettier and TSLint?
We don't feel we need this right now. And we don't want to remove prettier.
We don't feel we need this right now. And we don't want to remove prettier. @octref
First of all, many thanks for your work on Vetur - it has been great to see you joining the core team along with this project! We are looking forwards on utilizing Vetur more in our workflows.
We would like hear about your thoughts regarding Prettier and ESLint usage in general, and how are you seeing Vetur utilizing these in the future?
From the viewpoint of a developer transitioning to VueJS two years ago from Angular background, where the infrastructure and tooling setup ships pretty much all pre-configured, it took a lot of effort to realize that there seems to be certain tooling configurations that were simply not working well together... And there was no information clearly available that this should have been expected, or why it was so.
Considering developer experience with creating a new Vue project
When creating a new Vue project with Vue CLI by choosing TypeScript and Linter / Formatter features, you are given these options:
ESLint with error prevention only
> ESLint + Airbnb config
ESLint + Standard config
ESLint + Prettier
TSLint (deprecated)
Here I needed to choose ESLint + Airbnb config as my this client organization had previously opted for using Airbnb config. Today these configs bootstrapped for TypeScript + ESLint + Airbnb are working nicely out of the box.
However, after I've made these choices, does it mean I cannot use Vetur?
If so, is it because Vetur is dependant on Prettier, which in turn is kind of like competing with ESLint...?
If I cannot use Vetur, how I should be configuring VS Code then?
There seems to be no clear guidance on these questions for a newcomer... If there is indeed such a configuration options mismatch/exclusion, how could we in Vue ecosystem better communicate this to a newcomer?
I was here in 2019, and during in the last winter I posted this SO question, which till today remains unresolved as currently this seems to be a non-working setup (you may omit Styleint: How to configure Vue CLI 4 with ESLint + Prettier + Airbnb rules + TypeScript + Vetur?
Afterwards, I had an in-person chat about this topic with Evan. Soon after ESLint as formatter was released along with VS Code's Run Code Actions on save -feature.
Then I posted a new SO question for trying to solve the problem by self-answering my own configurations solution, which however doesn't seem to work ideally yet either: How to configure Vue CLI 4 with ESLint + Airbnb rules + TypeScript + Stylelint for SCSS, in VS Code editor with autofix on save?
I'd like to give Vetur a new spin to see if it works with TypeScript and Airbnb configs in VS Code. Does this seem viable now, or is it expected to work sometime in the future?
How about Stylelint (stylelint-config-recommended-scss) for linting SCSS files and SASS within SFC...or does Vetur already achieve the same, or is getting there?
However, after I've made these choices, does it mean I cannot use Vetur?
The reference above to the use of prettier is referring to the build environment of those working on the codebase, not the extension's support.
As I mentioned above that, pure eslint support looks appealing, and if I have some time I'm going to try and look into it myself, but for now, I've had success using the prettier-eslint formatter option in vetur and just omitting any prettier configs, it seems to work as well as can be expected until pure eslint is available.
Interesting @josh-hemphill, could you share your base configs in a repo or Gist etc? Which NPM packages and VS Code extensions are installed along with .vscode/settings.json and eslint configs?
@ux-engineer I've created an issue to track this, since it's not relevant to the general state of the roadmap. #2315
I'll post my current config there shortly.