Assets file name collision

[andrey-hohlov]

I want to open this issue again with one more case #2910
We have vue components and each component can have its own assets inside the components folder.

It was a matter of time when we come to a situation when two different components have two different images with the same name. Rename images? It's not a solution anyway.

For now, we use this temp workaround:

mix.extend('addHashToImagesFileNames', (webpackConfig) => {
  const imagesRule = webpackConfig.module.rules.find((rule) => {
    const { test } = rule;
    return test && typeof test.test === 'function' && test.test('.png');
  });

  if (!imagesRule) return;

  imagesRule.use.forEach(({ options }) => {
    if (options.name && typeof options.name === 'function') {
      options.name = (path) => {
        if (!/node_modules|bower_components/.test(path)) {
          return 'assets/images/[name].[hash:8].[ext]';
        }

        return (
          'assets/images/vendor/' +
          path
            .replace(/\\/g, '/')
            .replace(
              /((.*(node_modules|bower_components))|images|image|img|assets)\//g,
              ''
            ) +
          '?[hash]'
        );
      }
    }
  });
});
mix.addHashToImagesFileNames();

I have read the argument here #2911 (comment)
But why not do it optional? Just add addHashToFilenames option with default false value.

[Moriarty1982]

Why do you not only make subfolders for each component and copy it directly to the public dir?

[thecrypticace]

I think this is something we should fix as an opt in. But I also think the only proper way to do this is to include the hash in the filename itself and not in a query string for the file in the manifest.

If we do this it'll be in tandem with the switch to asset modules (see #3059).

[andrey-hohlov]

Why do you not only make subfolders for each component and copy it directly to the public dir?

Because there is no reason to not use imports.

In our case, it's about Vue components, but the problem is not about Vue only.

import image from './assets/images.svg';

is much simpler than worry about dist folders structure.

[Moriarty1982]

import image from './assets/images.svg';

is much simpler than worry about dist folders structure.

You really mean something like:

import image from './assets/images.5FADC12G.svg'
import image from './assets/images.19FA6C11.svg'

is easier to understand and maintain as something like:

import image from './assets/img/auth/image.svg'
import image from './assets/img/admin/image.svg'

[thecrypticace]

@Moriarty1982 in the current setup the 2nd import would result in asset collisions because the image names are both image.svg. The first list of imports is not something a user would write. It's what would be generated by the build process.

[Moriarty1982]

@Moriarty1982 in the current setup the 2nd import would result in asset collisions because the image names are both image.svg. The first list of imports is not something a user would write. It's what would be generated by the build process.

Ok I had use something like

mix.copyDirectory('resources/assets/images', 'public/images');

and then in the component:

<img src="/images/.../pic.svg" />

to get the pictures for the component, no hash is needed with this.

[thecrypticace]

Yes, that is an alternative option. But there are reasons one might not want to go that route. Either way it is something we change.

[aarbi]

The problem appears when for example you're referencing the logo of your website in different components.
I opened a PR associated to this issue: #3156 and added a test to showcase the scenario.

A similar workaround to the one mentioned in this issue, is attached to the issue I opened as well

[codemonkeynorth]

@thecrypticace does the code I noted in my reply here help?

#3211 (comment)

We had a similar issue with WPEmerge theme where assets weren't getting copied with subfolders. It needs path.relative ideally to retain folder structure from src to dist

another implementation here for relative paths:
webpack-contrib/file-loader#261 (comment)