Images in >0.30 in manifest have hashed path

[darrylhein]

When I update to >=0.30 (works fine in 0.29.1) the keys for images in the manifest are the hashed versions instead of the original paths. (I suspect fonts will be the same.) Prior to 0.30 I get:

"images/icons.svg": "/build/images/icons.677433a0.svg",

After 0.30 I get:

"images/icons.677433a0.svg": "/build/images/icons.677433a0.svg",

...which of course doesn't work :(

I'm import the image in my JS files.

I'm wondering if this is related to #771 though I'm still have the issue with 0.30.2.

I can reproduce the issue when updating webpack-encore (and sass-loader) on https://github.com/xmmedia/starter_wordpress

Let me know what other information you need.

[stof]

@darrylhein can you share the diff of your yarn.lock file for this upgrade (https://www.npmjs.com/package/yarn-lock-diff can probably be used to generate a summary of the upgrade) ?
This issue might be related to a upgrade of one of a dependency rather than a change in Encore itself.

[Lyrkan]

As discussed on Slack with @4c0n, it seems to be related to shellscape/webpack-manifest-plugin#209

We updated the file-loader in v0.29.0 which came with its esModule option set to true by default (so it should be broken in v0.29 as well).

A quick workaround would be to change that value to false using configureUrlLoader() (since we don't have a configureFileLoader()):

Encore.configureUrlLoader({
  images: {
    limit: 0, // Avoids files from being inlined
    esModule: false
  }
});

[4c0n]

@Lyrkan Thanks for looking into it so fast 😄 I'm just using copyFiles() in the webpack.config.js file to get the right result for now.

[darrylhein]

@stof Here's the "diff". I only changed the encore version in the package.json and then did yarn install in the hope to not update anything else unrelated.

I've tried @Lyrkan's suggestion, but didn't fix things and it appears to have removed the image files from the manifest all together. I could just copy the files, but I'd like them to be run through the svgo-loader.

Thanks for the help so far.

[Lyrkan]

I've tried @Lyrkan's suggestion, but didn't fix things and it appears to have removed the image files from the manifest all together

With the limit option set to 0 (or falseor any value lower than your filesize)?
If you don't set it, your files will be inlined as a base64 string, so no output file will be generated (and nothing will appear in the manifest).

[darrylhein]

Ah! I half ignored your code. Putting in just limit: 0 seems to resolve the issue – file is in the manifest without a hash and contains the right content. In my case, esModule: false doesn't seem to be required. (In debugging, I also disabled the svgo-loader but didn't seem to make a diff.)

I'm not exactly sure what this means – do we call this resolved? Should we document this somewhere? Or is it just something specific to my project config?

[Lyrkan]

Putting in just limit: 0 seems to resolve the issue

That'd depend on the version of the url-loader you added to your dependencies I guess (esModule defaults to true since v3.0.0).

I'm not exactly sure what this means – do we call this resolved?

Nah, that's definitely a bug, not sure what we can do on our side though (apart from setting esModule to false by default for the file-loader... which would, in my opinion, be a step backward).

[4c0n]

"By default, file-loader generates JS modules that use the ES modules syntax. There are some cases in which using ES modules is beneficial, like in the case of module concatenation and tree shaking."

https://webpack.js.org/loaders/file-loader/

I'm not really understanding why exactly it's causing the issue at hand though. The description seems rather unrelated?

[4c0n]

If it's actually file-loader that's causing the issue, then blacklisting the versions that cause the problem and reporting/fixing the problem on that end seems the best course of action IMO.

[Lyrkan]

If it's actually file-loader that's causing the issue

I don't think the file-loader has a problem, only that the webpack-manifest-plugin is not compatible with the esModule mode of it yet (enabled by default since file-loader@5.0.0). There is already an issue opened about that (see my first post).

[4c0n]

Alright, how about excluding the version until it's fixed then? Currently there apparently are compatibility issues that prevent this project from working properly. We should not just ignore that until the problem goes away, right?

[Lyrkan]

Alright, how about excluding the version until it's fixed then?

Sadly this isn't that simple.

There is no reason to exclude a version of the file-loader since the latest one should be compatible with the manifest plugin.
What's not compatible is the esModule option when it's set to true, the bug isn't present if it is set to false.

We could change that default value to false quite easily but it would mean that everyone will lose the benefits of the esModule mode by default, even if they are not impacted by that bug (I don't know how many people import images from their JS code and then try to read their path from the manifest).

Also it could introduce breaking changes since ES6 imports do not always behave the same way than CommonJS imports (see my comment here). Some people already had to change their code when that feature was introduced in 0.29.0.

At the end of the day, yes, that's definitely an issue, but there are some workarounds while waiting for it to be fixed upstream:

• setting the esModule option of the file-loader to false: there isn't any shortcut for it in Encore atm, but there are ways to do it (for instance by using Encore.configureLoaderRule(...) or by changing the generated config)
• using the url-loader instead of the file-loader (using Encore.configureUrlLoader(...)) with the right values for the limit and esModule options (depending on the version you added to your package.json)

[4c0n]

I mean excluding the version of webpack-manifest-plugin that introduced the issues and wait for them to fix it. How is that not an option? Sure workarounds exist, but that doesn't change the fact that currently it isn't working correctly out-of-the-box and it seems it could be. Saving us all the trouble of rediscovering the same problem and having to go look into it /for a workaround.