Vue-cli: Improve --skip-plugins

[Fl0pZz]

What problem does this feature solve?

I try use vue-cli ecosystem with yarn install --production.

For this i separate @vue/cli-plugins-*:
dependencies

• @vue/cli-service
• @vue/cli-plugin-babel

devDependencies

• @vue/cli-plugin-eslint

Then i try to build my app:

vue-cli-service build --skip-plugins @vue/cli-plugin-eslint

And got an error:
Error: Cannot find module '@vue/cli-plugin-eslint'

That's because the Service.js tries to find all the plugins first and skips some of them just to run them.

What does the proposed API look like?

I'll think, skipPlugins must use before resolvePlugin.

[sodatea]

Why do you use yarn install --production? What's the specific use case?

[Fl0pZz]

It is not a specific use case, it's recomendation from npm inc:
https://docs.npmjs.com/specifying-dependencies-and-devdependencies-in-a-package-json-file

"devDependencies": Packages that are only needed for local development and testing.

For production build i don't need install packages like jest or eslint, so i use yarn install --production for save CI time work

[sodatea]

Vue CLI plugins are meant to be development dependencies. More detailed explanations here: https://github.com/vuejs/vue-cli/issues/5107#issuecomment-605556617

[Fl0pZz]

@sodatea production deps is corejs, babel and build tools: vue cli (i need start build via vue-cli-service build), typescript (ts -> js)

[Fl0pZz]

and the issue (#5107) explain dependecies for node (node has own module resolution), however browsers does not support module resilution, so we need build app (for resolve deps)

So, build tooling must be dependecies

[sodatea]

"Build" is a development task. The production app only needs the built bundle.

[Zulcom]

"Build" is a development task. The production app only needs the built bundle.

So how to optimize build project on CI/CD? By moving unnecessary for build task dependencies to devDeps as recommended by package manager.

Why this issue can't be resolved? It's would be useful for me too. As I can see you don't use specific install keys so it's not a blocker for you or for project

[sodatea]

For whatever it's worth, you misunderstood the concept of "production dependencies".

[sodatea]

If it's skippable, then it should be inside "optionalDependencies" rather than "devDependencies" (Vue CLI do have special case handling for optionalDependencies so that it won't throw errors)

[sodatea]

And, I think it's very wrong to "optimize" CI in this way.
You can speed up the CI build by utilizing caches of the package manager. You should not bypass essential workflows like linting or testing. That defeats the exact purpose of linting and testing. They are meant to ensure the integrity of your CI builds.

[Fl0pZz]

@sodatea ok, imagine i builded my SPA app.

I can install core-js as a dependency and as devDependesies and my application will still be built without errors because the dependencies are resolved by webpack.

I agree with you that vue-cli is a development dependency, but only if we were making a node js application, because there dependencies can be resolved in runtime. But the frontend application is built into bundles with all its dependencies, and no matter what the dependecies of the package.json section say.

[sodatea]

@Fl0pZz
For front end projects:

• If it's a web app, then all dependencies are dev dependencies.
• If it's meant to be published as a library, then these are dependencies, and they should be "externalized" on building, the users of the library will need to install them.

As "dependencies" will be installed regardless of the environment, we chose the put those modules in the "dependencies" field for maximum compatibility across all use cases.

[Fl0pZz]

@sodatea Okay, that sounds convincing. However, the original question remains: why --scip-plugins does not work at the initialization stage?

[sodatea]

Sorry for the late reply.

It's because it's not the design goal of this flag - if you take a look at the original PR, it says this option is to "skip (plugins) for this run", meaning it's a one-off command that doesn't affect the original plugin loading logic.

Anyway, I feel it's okay to skip the plugin loading at all. Though, it's a low-priority for us to implement, given the abovementioned alternative workarounds.
You are welcome to open a PR to address this issue and we'll be glad to accept it, but we are not likely to implement it on our own in the foreseeable future.