webpack-contrib/copy-webpack-plugin

copy-webpack-plugin "ignore" option not working with dot files after update

Friends-for-Brands opened this issue Β· 20 comments

  • Operating System:
  • Node Version: 12.7.0
  • NPM Version: 6.10.0
  • webpack Version: 4.43.0
  • copy-webpack-plugin Version: ^6.0.1

Expected Behavior

Copy webpack plugin should be able to ignore dotfile .gitkeep.

Actual Behavior

In the previous major version of copy-webpack-plugin it was possible to ignore the .gitkeep file on build. Now it is being totally ignored.

Code

new CopyWebpack({
            patterns: [
                {
                    from: paths.images(),
                    to: paths.output.images(),
                    globOptions: {
                        dot: true,
                        ignore: ['.gitkeep']
                    }
                }
            ]
        }),

'**/.gitkeep' https://github.com/webpack-contrib/copy-webpack-plugin#ignoring-files

After adding this line which I have tried before your post returns:

unable to locate '/Users/nino/Documents/Projecten/Friends For Brands/WordPress-Starter-V4.0.0/src/fonts' at '/Users/nino/Documents/Projecten/Friends For Brands/WordPress-Starter-V4.0.0/src/fonts/**/*'

This folder exists in /src/fonts/ but is unable to locate it.

It means you have invalid path(s) in from

It means you have invalid path(s) in from

Can you clarify why it dit work in the latest version 5? I used this for months without issues.

@AndasDev because we update globby and globby uses fast-glob instead node-glob, it is in README for 6 version

If you provide reproducible test repo I can investigate, in theory it can be bug on fast-glob side, but i think it is a problem in the configuration, that is why we ask you to provide reproducible steps, but you just remove it from the issue template, and that’s why the issue was closed

If you provide reproducible test repo I can investigate, in theory it can be bug on fast-glob side, but i think it is a problem in the configuration, that is why we ask you to provide reproducible steps, but you just remove it from the issue template, and that’s why the issue was closed

I fully understand could be a configuration issue.

Here is my repo: https://bitbucket.org/associates/wordpress-starter-v4.0.0/ @evilebottnawi

It is expected, you run try to copy ./src/fonts/ directory, directory contains only one item .gitignore and you ignore it, so globby return [] empty list, we throw an error on this (previously it was warning), you can disable this behavior adding noErrorOnMissing: true

It is expected, you run try to copy ./src/fonts/ directory, directory contains only one item .gitignore and you ignore it, so globby return [] empty list, we throw an error on this (previously it was warning), you can disable this behavior adding noErrorOnMissing: true

Thanks for checking it out. So, where should the noErrorOnMissing check go?

Here docs https://github.com/webpack-contrib/copy-webpack-plugin#noerroronmissing

After adding that rule the .gitkeep is still being copied but when i add the **/ it will display the same previous error.

        new CopyWebpack({
            patterns: [
                {
                    from: paths.fonts(),
                    to: paths.output.fonts(),
                    globOptions: {
                        dot: true,
                        noErrorOnMissing: true,
                        ignore: ['.gitkeep']
                    }
                }
            ]
        }),

        new CopyWebpack({
            patterns: [
                {
                    from: paths.images(),
                    to: paths.output.images(),
                    globOptions: {
                        dot: true,
                        noErrorOnMissing: true,
                        ignore: ['.gitkeep']
                    }
                }
            ]
        }),
new CopyWebpack({
            patterns: [
                {
                    from: paths.fonts(),
                    to: paths.output.fonts(),
                    noErrorOnMissing: true,
                    globOptions: {
                        dot: true,
                        ignore: ['**/.gitkeep']
                    }
                }
            ]
        }),
new CopyWebpack({
            patterns: [
                {
                    from: paths.fonts(),
                    to: paths.output.fonts(),
                    noErrorOnMissing: true,
                    globOptions: {
                        dot: true,
                        ignore: ['**/.gitkeep']
                    }
                }
            ]
        }),

What a boss! Thank you very much man.

The resolution for this doesn't seem correct.

Ignoring ['**/.gitkeep'] is not the same as ['.gitkeep'], the former will ignore all files named .gitkeep irrespective were they are located in the directory tree, while the latter will only ignore the file in the cwd.

This bug is actually caused by this package, because it uses absolute paths in globs

pattern.glob = path.posix.join(
getAbsoluteContext(pattern.absoluteFrom),
'**/*'
);

pattern.glob = path.isAbsolute(pattern.fromOrigin)
? pattern.fromOrigin
: path.posix.join(
getAbsoluteContext(pattern.context),
pattern.fromOrigin
);

This break negative patterns when they don't contain **.

As a temporary workaround one can do the below;

new CopyWebpack({
  patterns: [
    {
      from: paths.fonts(),
      to: paths.output.fonts(),
      noErrorOnMissing: true,
      globOptions: {
        dot: true,
        ignore: ['.gitkeep'].map(i => path.posix.join(paths.fonts(), i)),
      }
    }
  ]
}),

That being said, the correct fix for this would be to remove absolute paths from the glob patterns.

@alan-agius4 Not quite right, but if you want to talk about it feel free to open an issue in fast-glob repo, because the globOptions option for fast-glob, we have no logic for ignore

I think I was wrong, can you open a new issue? No need reproducible test repo, I think we can fix it

@alan-agius4 paths.fonts is absolute path, right?

@alan-agius4 feel free to open a new issue

@evilebottnawi, yes. I’ll open a new issue later today/tomorrow.