Enhance MultiCompiler behavior with configuration dependencies

[enten]

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

feature

What is the current behavior?

Currently, we can define bundle dependencies by using the configuration options name and dependencies.

The multi-compiler will process configurations in an order determined by the dependencies defined.

In the current behavior:

• The multi-compiler will process every configuration even if an error occurred in a dependency's compilation.
• In watch mode, the multi-compiler will respects dependencies defined only in its first run.

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

What is the expected behavior?

• A configuration must not be processed if an error occurred in one of its dependencies.
• In watch mode, dependencies defined must be considered for each compilation.

For example, if we take the two configurations below:

• client which has no dependencies ;
• server which has one dependency to the client configuration.

When the multi-compiler process a multi-compilation with these configurations:

• If an error occurred with the client, the server will not be processed and the error is reported in its stats.
• In watch mode...
  • If a change affects the client only, the server must be invalidated when the client recompilation is over.
  • If a change affects the client and server, the client must be recompiled in first and the server in second.

I extended MultiCompiler to achieve that behaviors.

May a better implementation is possible if the multi-compiler shares events of its compilers between them?

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

Multi compilation is often used to compile an application which have dependencies between its bundles.

In the case of the client and server configurations: the compilation of the server can be done without any errors, but its running may not working if an error occurred in its client dependency.

It's like requiring a file A which itself requiring a file B which has a syntax error: the execution is interrupted even if the syntax error isn't with the file A. In the same way, if an error occurred in the client, these dependents may not working even if they compile successfully.

In watch mode, the fact that a change can invalid compilers without consider their dependencies constrained developpers to write fixtures for handle various cases like a new bundle is available but not their dependencies.

With these fixtures, developers try to resolve issues which can be solved natively by webpack through its management of configuration dependencies.

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

webpack <= 4

[sokra]

If an error occurred with the client, the server will not be processed and the error is reported in its stats.

It's difficult to say how critical the error is. Most errors only affect a small area of the codebase, probably only a simple file. webpack choose to continue building even with errors and don't stop the build. This has the benefit of a filled cached while watching. So you can do a incremental build after fixing the error.

There is a bail flag which opts-in to a different behavior. With bail = true, compilation is aborted as soon as one error happens. Not sure if it works correctly with the MultiCompiler, if that's broken feel free to fix it.

In watch mode...

It's was intended to not retrigger a depended build on finish. The depended build should instead retrigger itself if and only if one file it depends on changes.

So if server requires a output file of the client, it should detect the change automatically when the client finished building.

What was your use case? Why didn't it work for you?

[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.

[enten]

It's difficult to say how critical the error is. Most errors only affect a small area of the codebase, probably only a simple file. webpack choose to continue building even with errors and don't stop the build. This has the benefit of a filled cached while watching. So you can do a incremental build after fixing the error.

In my experience, we use webpack (without watch mode) to build project in a continous integration service (inside an ad hoc build container). In that way: the incremental build isn't useful.

So, when an error is thrown, we fixe it on a local development environment with the watch mode.

There is a bail flag which opts-in to a different behavior. With bail = true, compilation is aborted as soon as one error happens. Not sure if it works correctly with the MultiCompiler, if that's broken feel free to fix it.

I tried with the webpack config below and when there is an error with bundle A: the bundle B is still built. Did you think it's work correctly? Is the behavior that you expected?

module.exports = [
  {
    name: 'a',
    mode: 'development',
    entry: './src/a.js',
    output: {
      path: __dirname + '/dist/a'
    },
    bail: true,
    optimization: {
      noEmitOnErrors: true
    }
  },
  {
    name: 'b',
    dependencies: [ 'a' ],
    mode: 'development',
    entry: './src/b.js',
    output: {
      path: __dirname + '/dist/b'
    },
    bail: true,
    optimization: {
      noEmitOnErrors: true
    }
  }
];

It's was intended to not retrigger a depended build on finish. The depended build should instead retrigger itself if and only if one file it depends on changes.

So if server requires a output file of the client, it should detect the change automatically when the client finished building.

Often in universal application development: when the bundle B (server) depends to the bundle A (client): it's not reduced to the output file of the bundle A (client) because they shared lot of universal Javascript files.

So, when you update an universal Javascript file, the both compilers (managed by the multi-compiler) trigger a new build in parralel (even if dependency relations are set in webpack config).

It can be a nightmare to fix that behavior to order re-compilation which respect dependency relations. We experiment a solution with @ctrlplusb in react-universally 2 yars ago (2016). It's was not perfect but we concluded that can be more easier if webpack natively supports a mode to be strict with bundle dependencies (udk was born in 2017 to try to achieve that).

What was your use case? Why didn't it work for you?

In build mode: avoid bundle compilation if a dependency's compilation failed.

Currently, in a continuous integration service for example, a build with a webpack multi-compiler can be successfully even if a bundle failed.

In watch mode: when a shared file is updated, re-compile bundle in dependency relations order (and avoid re-compilation if an error occured in a compiler dependency).

How about create a new flag like strictDependencies which will avoid a compilation if a dependency failed?

In my opinion, this kind of feature can be really usefull for universal application development.

[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.

[enten]

@sokra
Please let me revive the discussion.

I think that webpack is an essential brick for so many projects.

Be strict with compiler dependencies in multi-compilation is necessary to allow better development experience (during dev and build stages). For example, we can enable HMR for universal angular application development in browser and server side.

I continue to maintain the udk package which try to achieve strict multi-compilation. But I would love that the MultiCompiler extension be a part of webpack. There will be more than 20k downloads of udk for 2018. It's not a lot but it may reflect a growing need of developers for strict multi-compilation.

[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.

[enten]

This issue is still opened.

[webpack-bot]

This issue had no activity for at least three months.

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.