Copy-webpack-plugin: Plugin goes into a loop and build doesn't complete

[davestewart]

• Operating System: Mac / Sierra
• Node Version: v8.11.1
• NPM Version: 6.1.0
• webpack Version: 3.2.1
• copy-webpack-plugin Version: 5.0.0

Expected Behavior

The copy webpack plugin runs and then the watch stops until further activity

Actual Behavior

The build goes into a loop:

Code

This is a Vue CLI 3 build using Webpack Chain:

    // copy all files from all module `plugins` folders  
    // @see https://github.com/webpack-contrib/copy-webpack-plugin
    config.plugins.push(new CopyPlugin([
      {
        from: 'src/modules/*/plugins/*.js',
        to: 'plugins',
        flatten: true,
      },
    ]))

How Do We Reproduce?

Let me know if you need more info and I will look into this.

[davestewart]

Going back to ^4.0.0 seems to solve this.

[alexander-akait]

@davestewart please create minimum reproducible test repo

[alexander-akait]

We don't modify hooks for webpack in new major release, so it is very strange

[davestewart]

OK, it's quite a big project, so let me find some time.

[alexander-akait]

@davestewart thanks!

[craigsumner]

I'm seeing looping behavior which might be related.

• Operating System: Windows 7
• Node Version: v10.10.0
• NPM Version: 6.5.0
• webpack Version: 4.29.5
• copy-webpack-plugin Version: 5.0.0
• webpack-dev-server Version: 3.2.1

The webpack-dev-server process repeatedly compiles.

It's fully correlated with copy-webpack-plugin version 5.0.0. Reverting to 4.6.0 resolves the issue. So does removing the copy directives from the plugin in webpack.config.js.

It's also largely correlated with a browser aimed at the server. I can't reproduce the problem by starting up the server on its own. I have to launch the page. And if I then close the browser, the looping eventually stops. Occasionally I can keep the browser up, and the looping will stop anyway, but that's a small minority of the time, and I can't reliably reproduce that. I get the feeling that loading the page causes something to seem 'dirty', so the server compiles. The compilation causes the page to reload, which causes a cycle.

I stripped my own javascript behaviors, so that my app didn't do anything but show static html, but the looping continued.

[0nky0]

i suffer from the same behavior once i've updated to version 5.

$ cat package.json | grep -i copy-webpack-plugin
    "copy-webpack-plugin": "^5.0.0",

trying to debug the issue, i noticed that when a wildcard is used for specifying which files to copy, the webpack build is going into infinite building\compiling loop.

dropping the wildcard (instead, specifying each file individually), bypasses the issue.
worth noting that going back to version 4.6 solves the issue.

apologies for not posting a testing repository.

[alexander-akait]

Please create minimum reproducible test repo.

Anyway problem can be when you use copy wetback plugin with glob (example dir/**/*, we add dir as context dependencies, so all changes in dir directory run recompiling) and other plugin something change (after copy-webpack-plugin) in this directory (rename/create file/change content), so you can get infinity build, it is expected, because you should not doesn't something in copied directory, copy webpack plugin for static assets. This behavior was changed in 5 version, because previously was wrong (we add only directory where file placed, so adding new files doesn't run recompiling).

[0nky0]

@evilebottnawi: thank you for the reply. though, i am not sure i understand you.

and other plugin something change (after copy-webpack-plugin) in this directory

when you say _"this"_, to which directory exactly do you refer -- the input\source-code directory or the output\distribution directory?

[alexander-akait]

@y0y0z directory which you use in from

[0nky0]

@evilebottnawi: from my inspection, nothing is changing in the from directory (i just copy static files). how do you advise to check whether any files are being written (inotify)?

[alexander-akait]

@y0y0z any tools, i don't know you os/filesystem. You can try to create minimum reproducible test repo, maybe something wrong and i can catch problem

[alexander-akait]

@y0y0z this PR https://github.com/webpack-contrib/copy-webpack-plugin/commit/49a28f07ea7fb235098a472e813ef2f96de4930e change behavior (before it was buggy)

[vonBrax]

If someone is still facing this problem maybe this can help.
I spent the whole day yesterday trying to figure out why webpack was entering the infinite rebuild loop or why now every file outside of webpack context (including webpack.config) was triggering rebuilds on change. All of this started after I updated a bunch of dependencies at once and so I had to roll back and reupdate one at a time until finding that it happened after updating to v5 of copy-webpack-plugin.
In my case the problem was that I was not passing in the context property to the plugin and using a glob for the from property to copy some files in some deep nested subdirectories. By taking a look in the PR pointed above ( #333 ) I saw that it is pushing the context to the webpack dependencies every time you use a glob (if you would pass in the files manually the condition would not be met and this would never happen) which in my case basically meant adding my root folder (and everything inside of it) to be watched by webpack since I was not defining context. And the output of html-webpack-plugin was being detected and triggering the infinite loop.
The solution that worked for me was to pass the context property as close as possible to where the files were in the subdirectories tree, right before the glob pattern.
Not sure if that's the best way to do it or if I even need these folders to be watched for changes since I rarely add or remove files from there. For my use case it seems like it is unnecessarily consuming resources and it would be nice if watching these folders was optional.

[alexander-akait]

@vonBrax Right solution :+1: This change was introduced because it is impossible works properly with glob without adding context as context dependency, new files can creating in difference place, so we should watch context to catch all changes

[alexander-akait]

Just for information, build system as grunt/gulp use same logic

[craigsumner]

Thank you @vonBrax for the instructions. That helped a lot.
I'll illustrate the changes I made:

Before:

    new CopyWebpackPlugin(
      [
        {
          from: 'node_modules/some-external-package/dist/**/*',
          to: 'webWorkerSupport/',
        },
        {
          context: 'src/',
          from: 'someInternalDirectory/images/**/*',
          to: '',
        },
      ],
      undefined
    ),

After:

    new CopyWebpackPlugin(
      [
        {
          context: 'node_modules/some-external-package/dist/',
          from: '**/*',
          to: 'webWorkerSupport/node_modules/some-external-package/dist/',
        },
        {
          context: 'src/someInternalDirectory/images/',
          from: '**/*',
          to: 'someInternalDirectory/images/',
        },
      ],
      undefined
    ),

[hongkheng]

Faced the same issue as well after the upgrade to v5.0.0. context has to be specified with the root directory for the from value. README.md might have to be updated with correct update instructions for v5 in case others face this issue after the upgrade.

[alexander-akait]

@craigsumner you can avoid **/*, if problem appear again after removing **/* please create reproducible test repo

@hongkheng README.md might have to be updated with correct update instructions for v5 in case others face this issue after the upgrade.

hm, before some people use invalid configuration, what we should update?

[alexander-akait]

Find a problem, WIP on this

[0nky0]

@evilebottnawi:
thank you for looking into it, investing time in fixing it and sharing it with us.
once you will release a new package\version, i will update and report back.

thanks again!

[alexander-akait]

Please test https://github.com/webpack-contrib/copy-webpack-plugin/releases/tag/v5.0.1, feel free to feedback, thanks

[0nky0]

@evilebottnawi:
upgrading to v5.0.1 seems to resolve the issue.
shipit! :)