Monorepo and Dependency Strategy for the CLI

[evenstensberg]

The new webpack-cli might be good for some folks but bad for others. When I ( as an FE dev) want to run webpack to compile my architecture I don't want to get more installation time because there's new features like the migration and initialization.

In the next couple of steps of the CLI's lifecycle we're gonna do the following ( like we've already done with webpack )

• Features like init and migrate are going to be published at webpack-addons and then we are going to ask the user to install the dependencies for a given feature if he/she hasn't installed it yet- This way, users can benefit from both having decreased bundle size as well as having the option to add utilities like migrate and init.

Ultimately, what I'd like to see, is a monorepo like the lighthouse team has for chrome-logger, chrome-launcher and similar. This way we can keep the packages in one repo to preserve a compact and clear structure of the CLI.

[montogeek]

What is the current structure of the repo, is there any parts that could be extracted into smaller packages?

[evenstensberg]

All the separate features like serve, init, migrate and so on. No separate packages yet, with the exception of the add-ons suite

[EugeneHlushko]

Is there a way to contribute? Who is going to create webpack-addons-xxx repos under webpack organization?

[evenstensberg]

Gonna take this up with the team later, soon finished with my assignments so that I can actually do something soon. Would be good to discard webpack add-ons and host the packages as a minorepo in webpack-cli

[billyjanitsch]

For one-off chores like init and migration, why not make each tool a separate pkg/CLI, and encourage users to run them using npx? e.g. npx webpack-init or npx webpack-migrate. Then users don't incur the cost of including them as dev dependencies.

I don't really see the purpose of a monolithic CLI that doesn't actually includes its features, especially when a great alternative exists via npx. It seems like a maintenance burden without any real advantage.

[evenstensberg]

Yes, that's the plan

[evenstensberg]

And while it is a burden, it allows us to be flexible around composition and we also allow people to use the AST transforms directly

[evenstensberg]

This is resolved and included in a newer version of the webpack-cli.