Vetur config file RFC #2378

yoyo930021 · 2020-10-14T14:09:53Z

Vetur configuration file.

victorgarciaesgi · 2020-10-14T14:46:54Z

This is really great!

I have nothing to comment at the moment, everything seems ideal (I don't use monorepos thought so I can't debate on this)

IlCallo · 2020-10-15T09:34:34Z

Put configuration to vue.config.js

I'd exclude this alternative, as there are other CLIs (Nuxt, Quasar, etc) which needs Vetur

Into "properties details > definition" you use monorepos property name instead of repos

Have you checked other frameworks config files for tasks similar to this? Angular/React/whatever? If yes, is it possible to have link to relevant resources/inspiration?

yoyo930021 · 2020-10-15T10:35:29Z

Put configuration to vue.config.js

I'd exclude this alternative, as there are other CLIs (Nuxt, Quasar, etc) which needs Vetur

Into "properties details > definition" you use monorepos property name instead of repos

Have you checked other frameworks config files for tasks similar to this? Angular/React/whatever? If yes, is it possible to have link to relevant resources/inspiration?

Thanks.
I fixed wrong text in RFC.

My first inspiration came from svelte.config.js.
sveltejs/svelte#1101
https://github.com/sveltejs/language-tools/blob/3139ccd5b4306a914be4ba64b0c036fcd8888f78/packages/svelte-vscode/README.md#generic-setup
The Svelte VScode extension read this file.
But the Svelte VScode extension don't have the support of monorepo.

The React and Angular are all officially supported by TypeScript for monorepo support.
They are all based on TypeScript program tsconfig.json,
And they don't have their own unique files to deal with.
PS. TypeScript is direct support for jsx.

yoyo930021 · 2020-10-15T13:31:29Z

I extend repos[].globallyComponents in RFC.
More consideration for customizable component names.

andrewisaburden · 2020-10-19T20:31:50Z

Grammar for globallyComponents is not correct; perhaps globalComponents or globallyRegisteredComponents?

yoyo930021 · 2020-10-21T12:41:14Z

Grammar for globallyComponents is not correct; perhaps globalComponents or globallyRegisteredComponents?

I rename to globalComponents.

antfu · 2020-10-24T07:20:15Z

globalComponents will help a lot to me! Really looking forward to this RFC get implemented! 👍

znck · 2020-10-24T07:14:27Z

rfcs/001-vetur-config-file.md

+
+export interface VeturConfig {
+  settings?: { [key: string]: boolean | string | Enum },
+  repos?: Array<{


repos is more connected to git repositories, and I get it, it's coming from monorepos but I feel it's not conveying the purpose.

Suggestion: We can call it projects. (typescript has project references and that makes it some what similar)

Maybe workspaces?

I agree. projects is better.

I like the "workspaces" name or maybe workingDirectories (stolen from eslint extension 😜)

workspaces also sounds good as package managers have those.

The workspaces word is also used for multi roots in VSCode.
It's a bit confusing.

As long as it's clear what it meant, it's ok, so +1 for projects.

Probably also allow a shorthand form, so

Array<string | { root: string, package?: string, tsconfig?: string, globalComponents?: Array<Glob | { name: string, path: string } >

Where string value is root.

It's a good idea.
I changed the RFC.

znck · 2020-10-24T07:17:00Z

rfcs/001-vetur-config-file.md

+    root: string,
+    package?: string,
+    tsconfig?: string,
+    globalComponents?: Array<Glob | { name: string, path: string }>


How about "extends" option to share configurations?

e.g.

module.export = { projects: [{ extends: ["vuetify"], globalComponents: ["./src/components/**/*.vue"] }] }

I don't understand what this setting means.
I think if we're going to share configurations, we can only use JS. Like require.

PS. When you use vuetify on package.json, we use component date to completion.
So you don't really need to define vuetify here!

Similar to tsconfig but it doesn't makes sense in cjs.

@znck I don't feel we need this. When you have:

vuetify listed in pointed package.json's dependencies

node_modules/vuetify/package.json has vetur key

Everything should work from there.

Unless you meant something else.

We need to support opt-in for external global components. (user can register, only a few components)

@znck What's a use case for that? If I understand you correctly, do you mean for the case when you have 2 UI lib and only want auto-completion for one of them (or only a few components out of a full library)? I feel there isn't much downside to just registering a whole library.

Mainly for type checking global components. If it's opt-in you can control what components are allowed globally.

I would prefer to use cjs directly.

module.export = { projects: [{ globalComponents: [ ...require('vuetify').components, "./src/components/**/*.vue" ] }] }

I also think there's no point in adding an external lib.
We don't know the details of external libs.
It may be difficult to get the correct TypeScript type when no correct tsconfig.json.

I would be inclined to expand the support for component data.
Let it have a type of marker.

In the TS plugin, I am using this to infer component meta. (It has a different structure compared to vetur's spec but includes verbose static information).

rfcs/001-vetur-config-file.md

octref

LGTM, except 2 small things:

repos -> projects
Allow projects to be an array of either the shortform (just a string pointing to root) or the longer form (root/package/tsconfig/globalComponents).

rfcs/001-vetur-config-file.md

octref · 2020-10-31T13:06:27Z

rfcs/001-vetur-config-file.md

+
+export interface VeturConfig {
+  settings?: { [key: string]: boolean | string | Enum },
+  repos?: Array<{


Probably also allow a shorthand form, so

Array<string | { root: string, package?: string, tsconfig?: string, globalComponents?: Array<Glob | { name: string, path: string } >

Where string value is root.

octref · 2020-10-31T13:07:27Z

rfcs/001-vetur-config-file.md

+    root: string,
+    package?: string,
+    tsconfig?: string,
+    globalComponents?: Array<Glob | { name: string, path: string }>


@znck What's a use case for that? If I understand you correctly, do you mean for the case when you have 2 UI lib and only want auto-completion for one of them (or only a few components out of a full library)? I feel there isn't much downside to just registering a whole library.

octref

LGTM, thanks for addressing the feedback.

znck · 2020-11-20T02:30:14Z

How would named component from external module work?

import { Foo } from 'foo'

app.component('MyFoo', Foo)

yoyo930021 · 2020-11-20T02:51:25Z

How would named component from external module work?
important { Foo } from 'foo'

app.component('MyFoo', Foo)

This RFC don't solves this problem.
Vetur currently uses component data to do this.
In the long run, we need a type-based mechanism.
I think we can discuss a new RFC about this.

The main goal is to resolve the registration of global components in own project in this RFC.
Not designed for external libraries.

znck · 2020-11-20T02:52:54Z

In the TS plugin, I am using the following data structure for the project config.

export interface ImportSource {
  moduleName: string
  exportName?: string
}

export interface ProjectConfig {
  root: string
  package?: string
  tsconfig?: string
  globalComponents: Array<string | Record<string, string | ImportSource>>
}

znck · 2020-11-20T02:55:11Z

What is the purpose of tsconfig option?

yoyo930021 · 2020-11-20T02:57:00Z

In the TS plugin, I am using the following data structure for the project config.

export interface ImportSource {
  moduleName: string
  exportName?: string
}

export interface ProjectConfig {
  root: string
  package?: string
  tsconfig?: string
  globalComponents: Array<string | Record<string, string | ImportSource>>
}

I think we can keep it that way for now.
If vetur introduces such an approach, it will have to face the problem of historical component data.

yoyo930021 · 2020-11-20T02:58:57Z

What is the purpose of tsconfig option?

The vetur will use this option to open the ts language service.

znck · 2020-11-20T03:27:04Z

TS Plugin can only use globalComponents, everything else is inherited from the TypeScript project.

yoyo930021 · 2020-11-20T03:30:05Z

TS Plugin can only use globalComponents, everything else is inherited from the TypeScript project.

You may also want to refer to the package.
It can be used to know the Vue version of the project.
What external libraries are used?

lanseria · 2020-12-09T06:30:03Z

Can you set the vetur version here, so that accidental upgrades don't cause problems?

yoyo930021 · 2020-12-09T06:33:17Z

Can you set the vetur version here, so that accidental upgrades don't cause problems?

It's practically impossible.
You only can use vetur.dev.vlsPath option to pin vls version.

Add vetur config file RFC

234e630

This was referenced Oct 14, 2020

intellisence relative to first tsconfig up from src #1360

Open

[VTI] Configuration options #2325

Open

Multi root support #424

Closed

Pick up tsconfig from non-top-level folder #815

Closed

yoyo930021 changed the title ~~Add Vetur config file RFC~~ Vetur config file RFC Oct 14, 2020

yoyo930021 mentioned this pull request Oct 14, 2020

[Feature request] Reference globally registered component to Vetur #2243

Closed

1 task

yoyo930021 mentioned this pull request Oct 15, 2020

Monorepo and vetur config file RFCs discussions #2380

Open

How to handle multiple vetur.config.js

1b7b439

New find vetur.config.js logic

1bff568

yoyo930021 force-pushed the vetur-config-file-rfc branch from 5d1feb2 to 1bff568 Compare October 15, 2020 10:22

Fix wrong word in VeturConfig

d4df749

yoyo930021 added 2 commits October 15, 2020 18:50

Fix typo in how to find config file

2a3858c

Extend repos[].globallyComponents in RFC

cb77392

yoyo930021 mentioned this pull request Oct 21, 2020

jsconfig for vue-project in subfolder #2393

Closed

3 tasks

yoyo930021 added 2 commits October 21, 2020 20:31

Rename to globalComponents

e2c6396

Remove misleading information

27a8a37

Remove wrong default in tsconfig

04dfb56

znck reviewed Oct 24, 2020

View reviewed changes

octref requested changes Oct 31, 2020

View reviewed changes

yoyo930021 added 3 commits November 2, 2020 13:47

Optional for globalComponents property

a06587a

Add a shorthand when only root in repos

0ea29db

Rename repos to projects

156cb96

yoyo930021 requested a review from octref November 2, 2020 05:58

octref approved these changes Nov 2, 2020

View reviewed changes

znck mentioned this pull request Nov 5, 2020

Support global components vuedx/languagetools#49

Closed

3 tasks

yoyo930021 mentioned this pull request Nov 19, 2020

Throws error about multiple root elements in template. (Vue 3 + TypeScript) #2299

Closed

yoyo930021 mentioned this pull request Nov 24, 2020

Impl monorepo and vetur config file support #2495

Merged

13 tasks

Add snippetFolder in projects

dbc38bf

yoyo930021 force-pushed the vetur-config-file-rfc branch from fb6cf94 to dbc38bf Compare November 26, 2020 08:39

yoyo930021 merged commit eb4f7f6 into master Dec 8, 2020

Vetur config file RFC #2378

Vetur config file RFC #2378

Conversation

yoyo930021 commented Oct 14, 2020

victorgarciaesgi commented Oct 14, 2020

IlCallo commented Oct 15, 2020

yoyo930021 commented Oct 15, 2020 • edited

yoyo930021 commented Oct 15, 2020

andrewisaburden commented Oct 19, 2020

yoyo930021 commented Oct 21, 2020

antfu commented Oct 24, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

znck Oct 31, 2020 • edited

Choose a reason for hiding this comment

yoyo930021 Nov 2, 2020 • edited

Choose a reason for hiding this comment

yoyo930021 Nov 2, 2020 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

octref left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

octref left a comment

Choose a reason for hiding this comment

znck commented Nov 20, 2020 • edited

yoyo930021 commented Nov 20, 2020 • edited

znck commented Nov 20, 2020

znck commented Nov 20, 2020

yoyo930021 commented Nov 20, 2020

yoyo930021 commented Nov 20, 2020 • edited

znck commented Nov 20, 2020

yoyo930021 commented Nov 20, 2020

lanseria commented Dec 9, 2020

yoyo930021 commented Dec 9, 2020

yoyo930021 commented Oct 15, 2020 •

edited

znck Oct 31, 2020 •

edited

yoyo930021 Nov 2, 2020 •

edited

yoyo930021 Nov 2, 2020 •

edited

znck commented Nov 20, 2020 •

edited

yoyo930021 commented Nov 20, 2020 •

edited

yoyo930021 commented Nov 20, 2020 •

edited