Monorepo Support RFC

[yoyo930021]

How do we support monorepo, sub folder, multi workspace?

Rendered

[mesqueeb]

rendered url is broken!

[yoyo930021]

rendered url is broken!

Sorry, I fixed it.

[kytosai]

After reviewing your post, I found this to be a good idea, it makes it easy to dynamically install everything about vetur configuration in the project.

However, I do not fully understand the case if the vetur.config.js file is not in the root directory, how will vetur handle?
(For example, will vetur ignore any vetur.config.js files that are not in the root folder?)

If you open a project with many vetur.config.js files, how will vetur handle everything?

---

To make this topic easier to follow, I think you should pin this rfc somewhere!

I really look forward to this problem solved!

[yoyo930021]

After reviewing your post, I found this to be a good idea, it makes it easy to dynamically install everything about vetur configuration in the project.

However, I do not fully understand the case if the vetur.config.js file is not in the root directory, how will vetur handle?
(For example, will vetur ignore any vetur.config.js files that are not in the root folder?)

If you open a project with many vetur.config.js files, how will vetur handle everything?

To make this topic easier to follow, I think you should pin this rfc somewhere!

I really look forward to this problem solved!

I forgot to specify the behavior of vetur.config.js on RFC.
My initial thought is that it will always read only the workspace root.
Ignore all vetur.config.js except the workspace root directory.
I will add to vetur.config.js RFC.

[yoyo930021]

After reviewing your post, I found this to be a good idea, it makes it easy to dynamically install everything about vetur configuration in the project.
However, I do not fully understand the case if the vetur.config.js file is not in the root directory, how will vetur handle?
(For example, will vetur ignore any vetur.config.js files that are not in the root folder?)
If you open a project with many vetur.config.js files, how will vetur handle everything?
To make this topic easier to follow, I think you should pin this rfc somewhere!
I really look forward to this problem solved!

I forgot to specify the behavior of vetur.config.js on RFC.
My initial thought is that it will always read only the workspace root.
Ignore all vetur.config.js except the workspace root directory.
I will add to vetur.config.js RFC.

Notice: The only exception is when the VSCode Multi root, Vetur will read all roots vetur.config.js acting on the respective root.

[Minigugus]

@yoyo930021 I'm not sure if you really understood my PR (#1734):

• PS. Slightly different is that the project relies entirely on TS plugins This has nothing to do with TS plugins, I just extended the fact that currently, Vetur create only 1 unique language service for the workspace root, thus only the root tsconfig.json is read. No plugin added.
• It will make one Project to one TypeScript program. To be clear: that's not really TypeScript program but TypeScript Language Service (do not create subprocesses if it's what you thought). Also, in the TypeScript jargon, a Project corresponds to a tsconfig.json and the associated files in its directory sub-tree.
• Because only TS feature needs this feature at the moment The TS Language Service is used for JavaScript as well (your sentense seems incomplete by the way)
• It may create something completely unnecessary TS program when having project no Vue, maybe need a lazy logic? TS program language services are already created lazily, when a file is openned. Also, if there is only 1 root tsconfig.json in the project, only 1 TS program will be created, which is equivalent to the current implementation, with very similar memory and CPU consumption.
• In the vue ecosystem, it isn't support multiple tsconfig.json, It's a little redundant It is the Vue ecosystem that has integrated TS support, and not the other way around... Not supporting this behavior in Vetur will only slow down its development in the Vue ecosystem... Moreover, it force users to rearrange their folder structure for aliases issues to work. All thoses issues are solved by Pick up tsconfig from non-top-level folders #1734. I think Vetur should support multiple tsconfig.json, and it's the reponsability of the user to either use compatible tools or to have a correctly folder structure. It could also be configurable under a flag in settings.
• Performance is affected by the interplay between projects. unless the separation process is implemented with node worker_threads TS language services are not workers, it's just a library for parsing TS files. Every time a request is received (code completion, file validation), a TS language service handle it. What is not working with Vetur currently is that since there is only 1 root language service, only the root config in tsconfig.json is used to serve requests. There is no need for a TS plugin or any other processes.
• The template interpolation need to refactor and design. No need in Pick up tsconfig from non-top-level folders #1734 😄 The interpolation of the model is also supported by a TS language service (with a different configuration than the JS code), so it works best with several language services (respect local tsconfig.json changes) 😉
• Because there is no defined project in VLS, register globally components could be inaccurate. Not yet tested, it depends on how TS and VLS handle globally registered components. Help appreciated 😄

[yoyo930021]

@yoyo930021 I'm not sure if you really understood my PR (#1734):

* `PS. Slightly different is that the project relies entirely on TS plugins` This has nothing to do with TS plugins, I just extended the fact that currently, Vetur create only 1 unique language service for the workspace root, thus only the root `tsconfig.json` is read. No plugin added.

* `It will make one Project to one TypeScript program.` To be clear: that's not really _TypeScript program_ but _TypeScript Language Service_ (do not create subprocesses if it's what you thought). Also, in the TypeScript jargon, a _Project_ corresponds to a `tsconfig.json` and the associated files in its directory sub-tree.

* `Because only TS feature needs this feature at the moment` The TS Language Service is used for JavaScript as well (your sentense seems incomplete by the way)

* `It may create something completely unnecessary TS program when having project no Vue, maybe need a lazy logic?` TS ~program~ language services are already created lazily, when a file is openned. Also, if there is only 1 root `tsconfig.json` in the project, only 1 TS program will be created, which is equivalent to the current implementation, with very similar memory and CPU consumption.

* `In the vue ecosystem, it isn't support multiple tsconfig.json, It's a little redundant` It is the Vue ecosystem that has integrated TS support, and not the other way around... Not supporting this behavior in Vetur will only slow down its development in the Vue ecosystem... Moreover, it force users to [rearrange their folder structure for aliases issues to work](https://github.com/vuejs/vetur/issues/762#issuecomment-599272491). All thoses issues are solved by #1734. I think Vetur should support multiple `tsconfig.json`, and it's the reponsability of the user to either use compatible tools or to have a correctly folder structure. It could also be configurable under a flag in settings.

* `Performance is affected by the interplay between projects. unless the separation process is implemented with node worker_threads` _TS language services_ are not workers, it's just a library for parsing TS files. Every time a request is received (code completion, file validation), a TS language service handle it. What is not working with Vetur currently is that since there is only 1 root language service, only the root config in `tsconfig.json` is used to serve requests. There is no need for a TS plugin or any other processes.

* `The template interpolation need to refactor and design.` No need in #1734 😄 The interpolation of the model is also supported by a TS language service (with a different configuration than the JS code), so it works best with several language services (respect local `tsconfig.json` changes) 😉

* `Because there is no defined project in VLS, register globally components could be inaccurate.` Not yet tested, it depends on how TS and VLS handle globally registered components. Help appreciated 😄

I'll answer them one by one.

• That note is describing example from angular. It's not about your PR.
• I'm a little lazy. It should be TypeScript Language Service.
  There is also a corresponding TypeScript program inside each TypeScript Language Service.
  But the purpose of this TypeScript program should be to compile and provide diagnostics.
• I'll add that to the RFC.
• Here's what I'm thinking about when a project without a Vue file has tsconfig.json in it.
  In a monorepo, The front-end projects may be mixed with library projects.
  In your PR, We can avoid this problem, because it create TS Language Service when we need.
  That's what I mean by lazy logic.
• But it's practically impossible now and unnecessary to have multiple tsconfig.json in a Vue project.
  The only thing you're experiencing is that the files are in the wrong place.
  So I'm going to be able to specify the location of a Vue project file through tsconfig.json file.
  If the first hypothesis is correct, the whole model would work just like any other ecosystem.
  Basically, this change does not affect other pure JS or TS projects, as they are directly responsible for the TS service without going through us.
• Now we have an issue where the TS Language service is too slow and is crowding out other features. Like: CSS LESS.
  So there is a risk that the more TS language services will also crowd out each other's resources, making VLS even slower.
  The solution here is to put the TS Language service in a separate process.
  It's as if VSCode would open two tsserver processes to do different things.
  PS. There are other problems with slow TS Language service, and we're working on them. Pass version in new template sourceFile for ts perf #2374 Stop computing outdated diagnostics with CancellationToken #2332 Reduce recreate ts program when no need for ts perf #2328
• The problem doesn't seem to be what I thought it would be right now.
  But I'm not sure if we'll break anything if we let Template interpolation have multiple files importing from each other.
• ok

Also I would like to know if React and Angular will have multiple tsconfig.json in a project?
All I know is like a test or a library, It's not really our problem.

Thank you for your thoughts at the end.
I'll be fixing the RFC.
If you have any more questions about my thoughts, please post them in the comments.

[mesqueeb]

Hi @yoyo930021
I just want to mention that until now I've used vanilla Lerna with monorepos and NPM. This means that all "packages" had their own node_modules.

However, since NPM released NPM Workspaces (I didn't wanna use Yarn), I will start using NPM Workspaces with my lerna projects soon, which will have a single node_modules folder at root level.

I just thought I'd mention here when considering monorepo support. If this is unrelated to Vetur feel free to ignore or mark this as spam! ;)

[yoyo930021]

Hi @yoyo930021
I just want to mention that until now I've used vanilla Lerna with monorepos and NPM. This means that all "packages" had their own node_modules.

However, since NPM released NPM Workspaces (I didn't wanna use Yarn), I will start using NPM Workspaces with my lerna projects soon, which will have a single node_modules folder at root level.

I just thought I'd mention here when considering monorepo support. If this is unrelated to Vetur feel free to ignore or mark this as spam! ;)

Hi @mesqueeb
I took a look at the npm workspace RFC.
It's basically the same as yarn workspace.
I don't think there's a support problem.

[kytosai]

I really look forward to this RFC.

When will you start implementing this RFC?

[yoyo930021]

I really look forward to this RFC.

When will you start implementing this RFC?

I expect to add the RFC to the last way I want to implement it.
That's what we're going to try to do next.

[yoyo930021]

I add final implementation in RFC.
Thanks for @Minigugus @vojvodics. This RFC wouldn't have happened without your quest.
Thank you all for your suggestions.

I will try to implement it. Scheduled to release on v0.31.0.