Open yekver opened 5 years ago
I don't think that this should be the responsibility of the CLI, simply because there's not "one way" to set up a multiproject repo.
You can use i.e. lerna and/or yarn workspaces to set up a monorepo workflow and then define commands in the main package.json
that call commands in the subprojects, i.e.
{
"proj1:serve": "cd project1 && vue-cli-service serve"
}
your concrete example doesn't work since you did not provide the correct path to the entry:
npx vue-cli-service serve ./admin/src/main.js
@LinusBorg @yyx990803 I think there are several good arguments for creating ways to manage monorepos with Vue CLI, that the core vue team should look at. I also want to offer some ideas about what this could look like.
Why are monorepos important? Nearly every major Vue library is using them (including @vue/cli). They are essential for standardizing build tools and project config across multiple node packages and applications. There are at least 3 common configurations that are being used by a large swath of the vue community:
Also, since build tools are a big part of any monorepo setup, and Vue CLI provides some great standarads in build tools, I think it just makes sense to have some standard defaults for the community to follow. I think it would be extremely beneficial for the Vue CLI to work with, not against, monorepo configuration.
Argument 1: It fits with Vue's core values of having things work out of the box, while allowing you to do things different later. Nothing about supporting monorepos in vue-cli says people need to use it, but for those who just want to use the recommended setup, it could save literally days.
Argument 2: It enhances the growth of the Vue community. Having a recommended "works out of the box" monorepo would allow vue users to more quickly start publishing Vue libraries, and would provide a common language for doing so (but of course would not restrict anyone for setting up a monorepo their own way).
An example of a cli that alrady supports a monorepo configuration: Nest JS. Here are a few takeaways that I think could also be appliccable to the Vue community:
Projects consist of libraries (reusable JS modules imported with @domain/lib
), and apps (stand-alone applications or microservices.
Something similar to the libraries function would allow vue users to quickly scaffold vue libraries that would follow best practice by default.
The "Apps" feature would allow vue users to maintain several vue projects in one repo. This would work well for all the common use cases I've mentioned, and more.
Projects start in "Standard mode", with just one src folder. Then if you add apps, the project is migrated into "Monorepo mode" with the multiple-app structure. This allows me to start projects small, and expand them as necessary.
The folder structure of a Nest monorepo is pretty simple. There are just an apps
folder and a libs
folder in the root directory. Each project is a canonical nest app, complete with it's own src
folder. The only difference is that limited config files are generated for apps, as they use the base .prettierrc
et. al. files by default. Everything is transparent and very flexible.
The monorepo structure is automatically generated into a nest-cli.json
folder, where package names, folder names, etc can be easily changed.
Several things that make the Nest CLI experience extra great, that I would love to have on my front-end projects:
npm install
cd
into the correct sub-folder first.If for some reason you still don't want to add a monorepo feature to Vue CLI, it would be great to have an easily replicatable example of a Vue monorepo, i.e. a github repo that can be easily cloned. Or better yet, an optional monorepo plugin. While these are second-rate options in my opinion, I think they better than having zero support for monorepos.
I hope you will consider adding a similar feature set to Vue CLI. Let me know if there's any way I can help, or if there's any more information you'd like me to provide.
Thanks!
Use env variable: VUE_CLI_SERVICE_CONFIG_PATH=path-to-vue.config.js vue-cli-service
to achieve what you want.
When a subfolder exists in the project named "client" and contains a vue project, do the following:
vue-cli-service serve ./client/src/main.js
What problem does this feature solve?
I have this folder structure:
And I would like to run vue-cli-service for subfolders (client, admin) to build them separately. But it's failed with an error:
What does the proposed API look like?
There should be an ability to have just one package.json files in root and have different configs for projects located in subfolders.