webpack-cli@4 installs 4x number of deps compared to v3 (including entire babel toolchain)

[AviVahl]

Describe the bug

Not really a bug, but an observation.
I have a typescript-based project that uses webpack@4 and webpack@3. When upgrading to webpack-cli@4 (alongside webpack@5), I've noticed a TON of new dependencies. More than v3. More than webpack itself.

Most of those come from cli-related packages installing jscodeshift to every consumer.

What is the current behavior?

webpack-cli@4 installs 668 dependencies.
In comparison, webpack-cli@3 installs 185 dependencies, webpack@5 itself installs 121 dependencies.

To Reproduce

Create a new project and install the new webpack-cli version.

Expected behavior

Be light? Avoid installing 600+ extra dependencies for those who just want to execute webpack via cli.

Additional context

One might consider that to be "expected behavior", but I look at it as regression.

@sokra @evilebottnawi webpack@5 decreased the number of dependencies vastly by dropping all those node@6 pinned versions. The cli did exactly the opposite. :(

[lopopolo]

This was previously brought to the webpack team's attention in the v4 beta feedback: https://github.com/webpack/webpack-cli/issues/1222#issuecomment-697154223, https://github.com/webpack/webpack-cli/issues/717#issuecomment-697282165

[alexander-akait]

Yes, it is on top issues for [email protected]

[alexander-akait]

@webpack/cli-team what about if we will install some packages inside generator package? It reduces side very well

[billyjanitsch]

From https://github.com/webpack/webpack-cli/issues/717#issuecomment-706538959:

We search way to not remove it, but reduce size

@evilebottnawi I appreciate your effort but it's less about the install size and more about the _number_ of installed deps, and the effects on the rest of the dependency tree. For example, jscodeshift includes almost all Babel 7 packages. When Babel 8 is released, this will cause an explosion of deps duplication in any project that uses it. yeoman-generator similarly installs hundreds of transitive dependencies, and each one that differs in version from one already used by the project will cause further deduplication bailout. This is a problem even if each package individually is small.

If webpack-cli were an optional package, this wouldn't be an issue. I could write my own simple CLI wrapper for webpack. But webpack-cli is tightly coupled to webpack. For example, webpack-dev-server errors unless you have webpack-cli installed. So if webpack is going to require that the official CLI be used, then it's important that the CLI isn't such an intrusive install.

webpack itself has improved significantly in this regard: v5 has far fewer deps than v4 did. But webpack-cli has regressed in the other direction.

As an aside, I don't quite understand why you want the init functionality as part of the CLI package to begin with. Init is only used once at project generation time and npm/yarn already have built-in init functionality. You could release a package like @webpack-cli/create and then users could run npm init @webpack-cli without ever having to incur the long-term dep cost of it. This also has better UX since users don't have to install webpack-cli before they can run this command. Is there a reason that this isn't preferable?

[alexander-akait]

@billyjanitsch Thanks for feedback

If webpack-cli were an optional package, this wouldn't be an issue. I could write my own simple CLI wrapper for webpack. But webpack-cli is tightly coupled to webpack. For example, webpack-dev-server errors unless you have webpack-cli installed. So if webpack is going to require that the official CLI be used, then it's important that the CLI isn't such an intrusive install.

We want to avoid this.

I think we should move out init/generator packages from webpack-cli, and install necessary deps on first run (first command run, so if you never run webpack init you will never have extra deps), so we keep DX for developers and reduce size of deps (and size of webpack-cli) after install. What do you think?

[rishabh3112]

I think we should move out init/generator packages from webpack-cli, and install necessary deps on first run (first command run, so if you never run webpack init you will never have extra deps), so we keep DX for developers and reduce size of deps (and size of webpack-cli) after install. What do you think?

Simple solution is to let the init package to not be integrated by default, that way when user runs webpack init first time, they will be prompted to install init package. That is same as what you said, installing it (and its dependencies) on first run.

[anshumanv]

Yes let's remove init as required dep, @rishabh3112 since you integrated it can you take care of removing it?

[rishabh3112]

@anshumanv
I am busy for this week with university work. In meanwhile, if you want, you can go ahead. After this week, I will do it anyway.

P.S.
Just to be clear. It was not solely mine decision to integrate it by default (as prompted by your comment), was decided at roadmap by cli-team as whole. Avoid pointing fingers on individuals when working as team and on the decision taken as a team.

[anshumanv]

No problem, no pointing fingers, the reason to ask you is you have more context on it than me 😄

[alexander-akait]

init is not installed by default, so less deps, some deps were removed, we will continue to reduce our deps