Webpack-cli: Discussion: New Output & Setting Defaults

[evenstensberg]

Summary

As the refactoring of webpack-cli is about to end, webpack-cli v4 is rolling out in near future, I want to ask the community for feedback on what they might find useful in webpack-cli and in the compilation output we give you. To be frank, the current output is not that pretty, on long compilations the output is easily bloated and the CLI is not ideal for beginners.

My questions are:

• What kind of output do you as a user find useful?
• What kind of output do you find not that much useful?
• Is there any interest in a perf section in output, indicating potential wins in chunks or duplications (if possible @sokra ? )
• Do you check the hash in the output of webpack, or is it in the way?
• Do you use the timestamps on compilation, or is it in the way?
• Is there too much output information in the code for you to make sense of?
• Do you feel like when getting an error message, you are stuck? Does errors help you?
• Are you struggling with the chunkSplitting API and getting it to work?
• Is the warning (attached as screenshot helpful, or is it in the way for you?)

In addition

i'd like to ask you if you feel like setting up webpack with sass, less and any other loader is a repetitive task(?) Do you feel like you spend a lot of time setting it up? For instance, do you use a lot of time to set up the configuration to use ES6 and React?

• Do you want webpack to care about setting up 0CJS with React without having to specify anything, or should it be the job of CRA?
• Should we bake in performance such as font-loading for you, or do you prefer to load fonts yourself?

Any feedback on this is appreciated, such as input on what you find cumbersome with the current compilation output, what you feel is missing of us etc. I want to get to know more about how you as a user use the output of a compilation so we can create a better experience for you!

This will most likely affect a lot of users, and I'll therefore require some input from various of people. Thanks for the attention!

CC @webpack/core-team @webpack/contributor-team (Internal) @addyosmani @developit (Google/Chrome DevTools) @gaearon (Facebook/React) @lencioni (AirBnB/User)

Feel free to comment any feedback you have on webpack CLI and what other things you mind find useful, i'd love to hear thoughts 👍

[DanielRuf]

Short: I began working on some CLI solution which asks questions like which CSS (pre)processing do you want to use, which browsers should be supported and so on and generate the config from small config parts and so on (webpack-merge, ...).

More like a scaffolding / prototyping solution to bootstrap better configs.

But the project is currently paused.

See https://github.com/DanielRuf/generator-webpack

[donaldpipowitch]

Thanks for the work.

• What kind of output do you as a user find useful?

• On successful (re)build - just log time and duration.
• On errors and warnings - explain _where_ and _why_ this happens and additionally with a link to some documentation page for further information (so the output in general keeps to be as "small" as possible).

• What kind of output do you find not that much useful?

• Very verbose or artificial warnings and errors.
• Name, sizes and amounts of chunks and so on.

• Is the warning (attached as screenshot helpful, or is it in the way for you?)

It's good. Nearly what I want. Could also be something like that in my opinion:

WARNING The 'mode' option in your configuration has not been set, webpack will fallback to 'production'. (Learn more: https://webpack.js.org/concepts/mode/)

With WARNING in _yellow_, The 'mode' option in your configuration has not been set, webpack will fallback to 'production'. in _white_ and (Learn more: https://webpack.js.org/concepts/mode/) in _gray_. 🙈

(At least for me this make it a little bit easier to read. Sometimes I personally highlight certain fields in the general message in _yellow_ for warnings or _red_ for errors like the concrete values: The ${yellow('mode')} option in your configuration has not been set, webpack will fallback to ${yellow('production')}. But this is a _very personal preference_.)

IMHO this is easier to read.

However I'd use a different link. Not https://webpack.js.org/concepts/mode/, but a page specific for this error. Something like: https://webpack.js.org/errrors/mode-not-set/ with specific instructions like the one from the original warning: The 'mode' option has not been set. Set 'mode' option to 'development' or 'production' to enable defaults for this environment. You can also set it to 'none' to disable any behaviour.

Benefits of this approach: You can be _much_ more detailed. I just searched for The 'mode' option has not been set. and my first hit was this SO question: https://stackoverflow.com/questions/49242756/how-to-set-mode-to-development-or-production-in-the-config-file
Some people already struggle with _Set 'mode' option_. A small example can help. I really like the error pages from MDN which all contain several examples which illustrate why something happens and how it can be fixed. (Like this one: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Errors/Not_defined).

But of course, this is a lot of effort.

• Do you want webpack to care about setting up 0CJS with React without having to specify anything, or should it be the job of CRA?

Maybe it should not be baked in, but easier to share and modify. Something like config presets. (Small Twitter thread about this topic.) Ideally CRA would be _just_ a webpack preset which can be imported in your own config and (if needed) modified)

[DanielRuf]

Maybe it should not be baked in, but easier to share and modify. Something like config presets. (Small Twitter thread about this topic.) Ideally CRA would be _just_ a webpack preset which can be imported in your own config and (if needed) modified)

Exactly what I thought about, a monorepo of configurations / configuration presets / configuration snippets which can be also require'd and consumed in many projects.

Was a very rough and first idea for an internal project (probably a stupid idea - the approach, not sure, was just an idea): https://github.com/DanielRuf/generator-webpack

[johnnyreilly]

Exactly what I thought about, a monorepo of configurations / configuration presets / configuration snippets which can be also require'd and consumed in many projects.

You may not be aware of it, but something of this nature already exists!

https://github.com/namics/webpack-config-plugins

cc @jantimon

[DanielRuf]

I know and I know namics but thanks. We had specific internal requirements (own configuration presets and own setup with a small footprint / less dependencies).

[DanielRuf]

Also we had an interactive CLI in mind, without npx / npm and and not a requirement to remember the right params.

[jantimon]

@DanielRuf could you go a little bit more in detail?
Actually the webpack-config-plugins offer both - A wrapper which configures everything at once and for example just the Typescript configuration or just the Babel configuration based on the recommended ts-loader configuration and on the create-react-app babel configuration

Take a look at the ts-config part for example:
https://github.com/namics/webpack-config-plugins/tree/master/packages/ts-config-webpack-plugin

It ships without a typescript dependency so you have to specify it by yourself and uses tested configurations of the ts-loader repositiory:

https://github.com/namics/webpack-config-plugins/blob/master/packages/ts-config-webpack-plugin/config/development.config.js

[DanielRuf]

Hi there @jantimon, a CLI is basically what the webpack-cli and so on do (prompts / inquirer, plop, yeoman, ...).

https://github.com/DanielRuf/generator-webpack/blob/master/index.ts#L12

What you do is basically shipping just some configs.
plugin !== generator ;-)

I hope you know what a CLI normally does (ask questions and do things depending on the answers given by the user).

https://github.com/namics/webpack-config-plugins/search?q=cli&unscoped_q=cli

[jantimon]

I know CLIs but thanks anyway.

My intend was to find out what part of https://github.com/namics/webpack-config-plugins could be improved to be a better match for your requirements.

Exactly what I thought about, a monorepo of configurations / configuration presets / configuration snippets which can be also require'd and consumed in many projects.

Because that's what this repository should be about:
configurations & configuration presets / configuration snippets
And it also provides plugins which automatically load those presets for you :)

[DanielRuf]

Because that's what this repository should be about:
configurations & configuration presets / configuration snippets
And it also provides plugins which automatically load those presets for you :)

I guess it is more about the current structure of the CLI which already ships such examples as JSON strings / objects which are merged and then written to the config files.

Not a JS API which is used as plugin (more abstraction and so on).
But it could be interesting to find the right approach. But the CLI is basically use once and then use the result of it. It is not a dependency of projects in general (mostly project configuration scaffolding).

[evenstensberg]

What do you think about these flags for CLI and having advanced flags configurable through configuration file instead?

https://github.com/webpack/webpack-cli/blob/c3371dad55bdfffe89a86824edb11c5ed0615939/lib/utils/cli-flags.js#L89-L290

[DanielRuf]

In general this is just a small part of webpack options (and additional plugins and plugin options as we already saw in the past, for example to scaffold a scss setup or PostCSS setup just as an example).

But at least something.