We're just waiting on the stable release: https://github.com/danethurber/webpack-manifest-plugin/releases

Technically, I believe we could use the RC1 as a package and NOT wait for stable... but hopefully it'll happen soon - I pinged the maintainers.

@weaverryan @Lyrkan The new version of Webpack manifest version has been released : https://github.com/danethurber/webpack-manifest-plugin/releases

@JohanLopes Yep, waiting for #164 to be updated and merged before rebasing that one :)

Ok, #164 is merged! go go go! :)

@weaverryan I rebased it but I'm a bit annoyed by some of the test results:

Encore.copyFiles([{ from: 'images/symfony_logo.png', to: 'symfony_logo.[hash:8].png' }]);

// Expected manifest.json
{"build/symfony_logo.png": "/build/symfony_logo.ea1ca6f7.png"}

// Actual manifest.json
{"build/symfony_logo.ea1ca6f7.png": "/build/symfony_logo.ea1ca6f7.png"}

I'm not sure what to do about that...

Also (but less of an issue so I didn't include it in my tests):

Encore.copyFiles([{ from: 'images/symfony_logo.png', to: './symfony_logo.png' }]);

// Expected manifest.json
{"build/symfony_logo.png": "/build/symfony_logo.png"}

// Actual manifest.json
{"build/./symfony_logo.png": "/./build/symfony_logo.png"}

I just noticed that the first issue was already discussed there: shellscape/webpack-manifest-plugin#75 (comment)

So... nothing can really be done for now since the Copy Webpack Plugin doesn't expose the original filename (that PR could help though: webpack-contrib/copy-webpack-plugin#198).

Boooooooooooo

Just to throw out an idea... if we copied that plugin (yet again) to our code, are there some small changes that would allow us to have this feature? It's so important, I'd rather be pragmatic over pure.

Oh, and since you understand the problem well, I think you should give some good feedback on /webpack-contrib/copy-webpack-plugin#198 if it's the right approach (more than just 👍, mention why we need it & your issue - the maintainer is good about listening when somebody comes in with good technical knowledge).

Just seing this conversation.

I found a way to bypass this issue a little time ago, having a look at the following comment can help with solving this problem: webpack-contrib/copy-webpack-plugin#104 (comment)

The bypass is not very clean but it allows to generate a manifest with proper key when using hash.

@deguif I saw your comment but sadly I don't think this is generic enough to add into this PR (it would not work for some filenames/configurations).

I'm also not sure that webpack-contrib/copy-webpack-plugin#198 would be the right fix anymore... as some other people pointed out in that thread an event-based approach would probably be a better idea.

Clearly I don't think webpack-contrib/copy-webpack-plugin#198 is the right fix, it would also be redundant with the use of webpack manifest plugin.

I haven’t looked at the specifics, but if there is a workaround that would work for us, but not be exposed to our users (so if we change in the future, they won’t be affected), then we should check into it. It’s tough, this is such an important feature but one that has been continually blocked.

@weaverryan I looked again at this PR today and I don't think there is a viable workaround.

Imagine that you have the following config (which is more or less the one I used for the failing functional test):

Encore.copyFiles([
  { from: 'images/symfony_logo.png', to: 'symfony_logo1.png' },
  { from: 'images/symfony_logo.png', to: 'symfony_logo2.png' },
  { from: 'images/symfony_logo.png', to: 'symfony_logo3.[hash:8].png' },
]);

What do you expect to get in the manifest file? Maybe something like this (which is what @deguif 's solution does if you only use the [name].[hash].[ext] pattern):

{
  'build/symfony_logo.png': '/build/symfony_logo1.png',
  'build/symfony_logo2.png': '/build/symfony_logo2.png',
  'build/symfony_logo3.png': '/build/symfony_logo3.ea1ca6f7.png'
}

But no... the key should actually always be build/symfony_logo.png because the left part is supposed to be the original name of the file (you can't guess what you're supposed to get from the final filename). This is annoying because currently the generated manifest would look like this:

{
  'build/symfony_logo1.png': '/build/symfony_logo1.png',
  'build/symfony_logo2.png': '/build/symfony_logo2.png',
  'build/symfony_logo3.ea1ca6f7.png': '/build/symfony_logo3.ea1ca6f7.png'
}

... which doesn't contain the original filename at all.

So, unless the CopyWebpackPlugin provides a way to get more info there isn't much we (or the WebpackManifestPlugin) can do... and then you'd probably still have some edge cases to handle.

I'm wondering if we couldn't do something simpler without the CopyWebpackPlugin... like creating a fake entry point that require the given files using the file-loader.

Closing that one since #409 has been merged :)