v4 does not print when the compilation starts and ends in watch mode

[jakebailey]

Is your feature request related to a problem? Please describe.

webpack-cli 3 printed "Compilation starting..." and "Compilation finished" in watch mode. This is critical for editor support, as the editor needs to know when it's safe to perform tasks once the code has changed by tracking when the build is running. E.g. I have a launch task in VS Code that starts webpack, and VS Code will know not to proceed with running anything until the code is packed. Similarly, if stop the running process and start it again having modified the code, the editor knows to wait for webpack to finish.

Describe the solution you'd like

webpack-cli 4 should restore this behavior, otherwise the existing webpack task runners in editors like VS Code will misbehave, likely hanging as they wait for a line to be printed that will never come.

v4 has a printed line for when it's watching for changes which indicates a possible end; my impression is that it'd be the place to stick these logs (but I haven't had the time to try and find it).

Describe alternatives you've considered

Currently, I'm just using webpack-cli 3 with the webpack 5 RC, since it "works" so long as I limit myself to API elements that didn't change.

I thought about writing a plugin that would print these lines, but that seems like a hack and error prone (as I really want to know when the files are going to stop changing).

The only thing I've gotten to sort of work when I have stats disabled is to have it print the webpack version; this is printed at the end so I see "webpack 5.0.0-rc.5 compiled", which gives me at least the end of run, but isn't the full start/end pair required by VS Code.

Additional context

webpack-cli/bin/cli.js

Line 294 in dd06d08

console.error("\nCompilation " + compilationName + " starting…\n");

[anshumanv]

Usecase seems valid, will PR in a while.

/cc @webpack/cli-team should we make this default behaviour when using watch mode?

[rishabh3112]

Yes, we should do this in my opinion.

[alexander-akait]

This is critical for editor support, as the editor needs to know when it's safe to perform tasks once the code has changed by tracking when the build is running.

This is a very bad idea.

Why do you use it?

We return this behavior because it's convenient, but I would not recommend relying on this

[jakebailey]

Thanks for the fix.

I'm surprised this would be regarded as a bad idea. It was my impression that this was not uncommon. This is one of the main ways VS Code extensions (and others) are developed:

• https://code.visualstudio.com/api/working-with-extensions/bundling-extension#run-webpack (webpack-dev task)
• https://code.visualstudio.com/docs/editor/tasks#_background-watching-tasks (similar thing with tsc)
• https://marketplace.visualstudio.com/items?itemName=eamodio.tsl-problem-matcher

I have a complicated extension with multiple entrypoints (for the extension, a language server, CLI), ts-loader, multiple copy plugins, use of __dirname to reference files, split bundles (thanks to webpack 5 splitting working in node), etc. Having a single way to run things makes things much simpler, isn't much slower than doing it manually, and is all-around faster in watch mode.

Anyway, the main thing I am confused about is that this is documented in the webpack 5 docs: https://webpack.js.org/configuration/watch/#info-verbosity

Controls verbosity of the lifecycle messaging, e.g. the Started watching files... log. Setting info-verbosity to verbose will also message to console at the beginning and the end of incremental build.

Reading the PR, it seems like this behavior will be different than documented. I previously saw PRs removing this flag; perhaps the docs need an update to correctly reflect how watch mode works, especially if the webpack 5 release is imminent.

[alexander-akait]

@jakebailey Can you open new issue and we will continue discussion for better approach?

[snitin315]

WIP for docs webpack/webpack.js.org#4051

[jakebailey]

I can open a new issue if you'd like, but I'm not certain which part of my comment is the one needing a better approach. Are you referring to the inconsistency with the docs, the new printing needing a flag, or not liking the overall scheme of using the printed lines at all?

[alexander-akait]

@jakebailey Yep, rely on our output is not safe, we can change our output - using other words/colors/etc

[jakebailey]

I opened #1908; if it's not what you meant to discuss, let me know. Hopefully you didn't mean the latter, since the logging definitely needs to be there for other tools to use. 🙂