Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vetur 1.0 Roadmap #873

Open
12 of 17 tasks
octref opened this issue Aug 13, 2018 · 25 comments
Open
12 of 17 tasks

Vetur 1.0 Roadmap #873

octref opened this issue Aug 13, 2018 · 25 comments
Labels

Comments

@octref
Copy link
Member

octref commented Aug 13, 2018

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:

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 this are 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.

Related issues: #424 #815

JSX Support

We have no support for JSX yet. This should be implemented as a TypeScript plugin, same as lit-html.

Issues:

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:

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:

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:

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:

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:

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.

@numfin

This comment has been minimized.

@octref
Copy link
Member Author

octref commented Aug 16, 2018

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!

@mittalyashu
Copy link

There is no option to fold the code.

@ericettensohn
Copy link

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.

@octref
Copy link
Member Author

octref commented Feb 6, 2019

@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.

@ericettensohn
Copy link

@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!

@dacarley
Copy link

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.

@jvik
Copy link

jvik commented Nov 27, 2019

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

@serializedowen
Copy link

is there any plan for mixin support?

@garyo

This comment has been minimized.

@qgates
Copy link

qgates commented Mar 7, 2020

@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.

@hnviradiya
Copy link

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?

@hikerpig
Copy link
Contributor

hikerpig commented Mar 9, 2020

@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 ?

@hnviradiya
Copy link

@hikerpig awesome. i just couldnt find this.

@ghost
Copy link

ghost commented Aug 4, 2020

still waiting for support for multiple roots.

Monorepo is becoming quite popular, and Vetur does not support it.

@Minigugus
Copy link

#1734 is still pending review...

@octref
Copy link
Member Author

octref commented Aug 10, 2020

@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.

@Minigugus
Copy link

@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?) 😉

@clouds56
Copy link

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?

@josh-hemphill
Copy link

josh-hemphill commented Sep 20, 2020

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)

@octref
Copy link
Member Author

octref commented Sep 21, 2020

@josh-hemphill

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.

@ux-engineer
Copy link

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?

@josh-hemphill
Copy link

josh-hemphill commented Sep 23, 2020

@ux-engineer

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.

@ux-engineer
Copy link

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?

@josh-hemphill
Copy link

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests