Angular-builders: Extending webpack configuration with plugin zaps assets directory from dist

[wballoni]

Describe the bug
When extending the Angular webpack configuration with another plugin, assets are no longer generated under the dist directory.

I have some files I want included in the build. They are in a newly created directory under src. I use a simple one line plugin spec for CopyWebpackPlugin to perform the copy. Upon running the build, I see my copy as expected in the dist directory, but the assets directory (in which I placed an image file in an images sub-directory) is no longer present under the dist directory.

To Reproduce
Steps to reproduce the behavior:

1. Create a new Angular application using ng new.
2. Install @angular-builders/custom-webpack, and copy-webpack-plugin.
3. Add files for the plugin to work on; I created a directory called i18n under src with a single file in it, en.json.
4. Add an images directory under src/assets; populate images directory with a single image file.
5. Add a custom webpack file (I added a file named webpack.extension.js) in the project root directory that includes a plugins section; my content below:

const CopyWebpackPlugin = require('copy-webpack-plugin');

module.exports = {
    plugins: [
        new CopyWebpackPlugin([{ from: './src/i18n/*.json', to: './i18n', flatten: true }])
    ]
};

1. Modify angular.json to specify customWebpackConfig:

      ...
      "architect": {
        "build": {
          "builder": "@angular-builders/custom-webpack:browser",
          "options": {
            "customWebpackConfig": {
              "path": "./webpack.extension.js"
            },
            "outputPath": "dist/test-app",
            ...

1. Run a build: npm run build.

Expected behavior
The expected result is that the dist directory includes my new directory, i18n, as well as the assets directory.

Actual behavior
The dist directory includes my new directory, i18n, but NOT the assets directory.

Builder:

• @angular-builders/custom-webpack
• 7.3.1

Libraries

• angular-devkit/build-angular: 0.13.1

Additional context

• If the CopyWebpackPlugin plugin is commented out in angular.json, the assets directory will be included under the dist directory.
• Zip of my test application reproducing the issue is attached: test-app.zip

[just-jeb]

Why wouldn't you simply use assets with glob pattern? This configuration is for Angular CLI 6, but while the docs for version 7 don't mention that, I think the globs are supported in 7 as well.
As for your specific problem, I think I have something very similar that works. I suggest you to take a look at this and see if you missed something. Please let me know if it still doesn't work, I'll try to figure it out.

[wballoni]

Thanks @meltedspark, I will take a look at your example and let you know.

You are correct that I could do what I described easier than extending webpack, I actually am doing something more complex with our own custom webpack plugin. But I didn't want to confuse things with complex scenarios and custom plugins. So I reproduced the problem we see as simply as possible.

BTW, nice work on this package. If it works for us it will be just what we need!

[wballoni]

@meltedspark, I took a look at your similar thing you linked above. Unfortunately, your assets directory is empty, so you won't see the bug I've reported. In my case I'm configuring a webpack plugin (again, not really CopyWebpackPlugin, but this simple plugin demonstrates my problem) AND I have some files in src/assets that don't make it to the dist directory on build when using the plugin.

[just-jeb]

Yep, you're correct.
It seems that the instance of CopyWebpackPlugin you define is getting messed up with the instance Angular CLI defines, probably because of the default merging behavior.
Could you please try mergeStrategies: {"plugins": "append"} and see if that helps?

[wballoni]

Well @meltedspark, I've given it a try but no luck. I added mergeStrategies (see below) as you asked but the same behavior (no assets) continues to occur.

      "architect": {
        "build": {
          "builder": "@angular-builders/custom-webpack:browser",
          "options": {
            "customWebpackConfig": {
              "path": "./webpack.extension.js",
              "mergeStrategies": {"plugins": "append"}
            },
            "outputPath": "dist/test-app",

Let me know if you need anything else.

[wballoni]

Bump. Any updates on this?

[just-jeb]

This is my next priority 🙂 Sorry it's taking time.

[just-jeb]

Meanwhile you can use the new feature that allows you to provide a function in your config that modifies the existing one. It is available in 7.4.1.
It can help you to analyze the final config that comes from Angular and understand how you should incorporate your changes.

[just-jeb]

It seems to work correctly in development (ng start). Could you confirm that please?

[wballoni]

Good news, using the exported function form worked. See snippet below:

const CopyWebpackPlugin = require('copy-webpack-plugin');

module.exports = (config, options) => {
    config.plugins.push(
        new CopyWebpackPlugin([{ from: './src/i18n/*', to: './i18n' flatten: true }])
    );
    return config;
};

With this form in place, and using @angular-builders/dev-server:generic, both build and serve work as expected. Not sure why the static webpack config is not working (I’ve confirmed it again), but at least I have a working solution. Thanks for your help!

[inpercima]

Hey there, same issue here but I can confirm that this variant works. I can work with it first

[just-jeb]

The problem is here.
If the plugin is not an instance of a class (but a closure with apply, like it was in copy-webpack-plugin) the merger will merge the two instances while overriding the first apply.

Regarding this specific problem (with copy-webpack-plugin), it should work with the newer versions of webpack (since this commit), so probably in Angular 8 the problem won't exist.

This issue still has to be tackled though, because no one can promise that all the plugins will be instances of classes.
One possible solution is to not merge instances of Object, thus having multiple instances of a plugin that is implemented as a closure.