Webpack not calling hooks in the right order?

[SirUppyPancakes]

Do you want to request a feature or report a bug?

bug/feature

What is the current behavior?

When writing a plugin and using compiler.hooks or compilation.hooks, hooks like afterEmit, afterCompile, and done are called before the actual compilation info/errors/warnings are logged to the console.

If the current behavior is a bug, please provide the steps to reproduce.

webpack_hook_issue.zip
Unzip the attachment, navigate to the root of the node application, run yarn install or npm install, and then yarn webpack or npm run webpack.

Inside of webpack.config.js, I have registered a small plugin, inline, which taps all of the hooks in compiler.hooks and compilation.hooks and logs a message.

As you make changes to src/test.js, you will notice that the output shows all of the hooks getting logged before the final bits of text:

Info:

...
webpack: compilation.needAdditionalSeal
webpack: compilation.afterSeal
webpack: afterCompile
webpack: shouldEmit
webpack: emit
webpack: afterEmit
webpack: compilation.needAdditionalPass
webpack: done
Hash: 8425def6e9a1fc30c3bc
Version: webpack 4.1.1
Time: 89ms
Built at: 2018-3-17 01:58:21
         Asset      Size  Chunks             Chunk Names
    Console.js  4.89 KiB    main  [emitted]  main
Console.js.map   4.7 KiB    main  [emitted]  main
Entrypoint main = Console.js Console.js.map
[./src/test.js] 116 bytes {main} [built]
    + 1 hidden module

Warnings:

...
webpack: emit
webpack: afterEmit
webpack: compilation.needAdditionalPass
webpack: done
Hash: d967bd3004e17b298d7e
Version: webpack 4.1.1
Time: 67ms
Built at: 2018-3-17 02:02:01
         Asset      Size  Chunks             Chunk Names
    Console.js  3.68 KiB    main  [emitted]  main
Console.js.map  3.36 KiB    main  [emitted]  main
Entrypoint main = Console.js Console.js.map
[./src sync recursive] ./src sync 160 bytes {main} [built]
[./src/test.js] 136 bytes {main} [built]

WARNING in ./src/test.js
2:16-29 Critical dependency: the request of a dependency is an expression
 @ ./src/test.js

Errors:

...
webpack: compilation.needAdditionalPass
webpack: done
Hash: ac3697133c4a4ef0999f
Version: webpack 4.1.1
Time: 30ms
Built at: 2018-3-17 02:02:33
         Asset      Size  Chunks             Chunk Names
    Console.js   3.2 KiB    main  [emitted]  main
Console.js.map  2.72 KiB    main  [emitted]  main
Entrypoint main = Console.js Console.js.map
[./src/test.js] 206 bytes {main} [built] [failed] [1 error]

ERROR in ./src/test.js
Module parse failed: Unexpected token (1:18)
You may need an appropriate loader to handle this file type.
| const leftPad = r equire("left-pad");
|
| console.log("hello");

What is the expected behavior?

Since Webpack does not output messages like Compilation started, Compilation completed successfully, Compilation completed with warnings, or Compilation completed with errors (which would be super helpful as a default config or any config), I attempted to make this small plugin, only to find that it couldn't handle a situation like this.

If this is a feature request, what is motivation or use case for changing the behavior?

Visual Studio Code problem-matchers: vscode-problem-matchers-docs
These use regex to detect sections of standard output that potentially have 'problems' and show them in the IDE, very cool stuff. Without messages from Webpack, we can't define robust matchers.

Please mention other relevant information such as the browser version, Node.js version, webpack version, and Operating System.

webpack: 4.1.1
webpack-cli: 2.0.12
node: v8.9.4
npm: 5.6.0
yarn: 1.5.1
vscode: 1.21.1
windows: 10.0.16299 build 16299

[sokra]

The webpack-cli supports a --build-delimiter argument.

[SirUppyPancakes]

While that works (with a combination of --info-verbosity verbose to delimit the start of a compilation block), the whole thing feels rather hack-y and incomplete. I'll be interested to know if all of the hooks are functioning properly (and actually expected to come before the compilation output).

[alexander-akait]

@SirUppyPancakes problem solved?

[SirUppyPancakes]

@evilebottnawi Nope, the problem still persists even with the latest Webpack and Webpack CLI ("webpack": "^4.11.1", "webpack-cli": "^3.0.3").

If I had to guess what would cause something like this, I would suppose that the code that handles the loaders and prints the section detailing the rebuild is implemented independently from the hook-system, which means that the order of the messages becomes a timing issue/race condition, albeit an ultimately harmless one. Though I am not familiar with the internals at all, it may be possible to implement the code that prints the messages for the rebuild details, as a sort of 'built-in' hook-handler which would cause it to be ordered properly in the hook-system. This may very well be an inordinate amount of work for a relatively small gain though :)

[webpack-bot]

This issue had no activity for at least half a year.

It's subject to automatic issue closing if there is no activity in the next 15 days.

[webpack-bot]

Issue was closed because of inactivity.

If you think this is still a valid issue, please file a new issue with additional information.