Two output files share the same path but have different contents: media/img.svg [plugin angular-compiler]

[ln-e]

Command

serve

Is this a regression?

• Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was

No response

Description

It is not possible to import in SCSS two or more files with the same name but located in different folders when using new esbuild builder@angular-devkit/build-angular:application during serve.

.main {
  background: url('../assets/subdir1/img.svg');
}
.content {
  background: url('../assets/subdir2/img.svg');
}

And problem appears only during serve, production build works as expected: its generate 2 different images in media folder with different hashes.
The only possible workaround I found is adding "outputHashing": "media" to development configuration.

Minimal Reproduction

https://github.com/ln-e/ng17-image-import-bug

1. Clone repo
2. npm run start

Exception or Error

✘ [ERROR] Two output files share the same path but have different contents: media/img.svg [plugin angular-compiler]


Application bundle generation failed. [1.409 seconds]

Your Environment

Angular CLI: 17.0.0
Node: 18.16.1
Package Manager: npm 9.5.1
OS: darwin arm64

Angular: 17.0.2
... animations, common, compiler, compiler-cli, core, forms
... platform-browser, platform-browser-dynamic, router

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1700.0
@angular-devkit/build-angular   17.0.0
@angular-devkit/core            17.0.0
@angular-devkit/schematics      17.0.0
@angular/cli                    17.0.0
@schematics/angular             17.0.0
rxjs                            7.8.1
typescript                      5.2.2
zone.js                         0.14.2

Anything else relevant?

No response

[clydin]

Using "outputHashing": "media" is the correct solution for applications in this scenario. The output filenames will otherwise have identical names as shown.
To help mitigate this problem, we can consider making this the default behavior in the next major version.
We can also adjust the error message to indicate that using the outputHashing option will solve the problem.

Also of note, by referencing files inside a directory that is configured to be copied as an asset via the assets option, the images are present in the output twice. Once via the assets option copying and again via the url() from the CSS bundling. If the images are intended to be processed and hashed during a production build, then the images should either be moved to a location not configured in the assets option or the assets option should be adjusted to not include their location. Conversely, if the assets should only be copied (and retain their respective directory structure), the CSS references should be adjusted to be relative to a runtime accessible location (i.e., ../assets/subdir1/img.svg --> assets/subdir1/img.svg) and the externalDependencies option should include assets/* to indicate the location should not be processed during the build.

[jnizet]

@clydin how and where to set the externalDependencies option? And is it possible to configure the name of the new media directory where the css media are copied? Because it could conflict with an existing route or other existing resources, and that can be a problem.

EDIT: OK, I've understood that externalDependencies is an option of the application builder, to add to the angular.json file. That's fine. The question about the customization of the media directory still stands though.

EDIT: According to #26057 (comment), I understand that customizing the media directory name is something planned.

[clydin]

If you use the externalDependencies option, the files will not be placed in the media directory and instead the location will be based on the assets build option configuration. The files will also not be hashed, so there is a tradeoff between the options.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}