[GH-ISSUE #1142] ESBuild not possible when using flag-icons #531

Closed
opened 2026-03-03 14:39:04 +03:00 by kerem · 54 comments
Owner

Originally created by @joewIST on GitHub (Aug 16, 2023).
Original GitHub issue: https://github.com/lipis/flag-icons/issues/1142

We have an Angular application inside an Nx monorepo. I'd like to start using ESBuild as a builder for improved build speeds, but we are currently blocked by flag-icons. The following errors occur and the build fails:

Two output files share the same path but have different contents: xx.svg

Is there anything we can do to avoid/fix this?

Much appreciated!

Originally created by @joewIST on GitHub (Aug 16, 2023). Original GitHub issue: https://github.com/lipis/flag-icons/issues/1142 We have an Angular application inside an Nx monorepo. I'd like to start using ESBuild as a builder for improved build speeds, but we are currently blocked by flag-icons. The following errors occur and the build fails: Two output files share the same path but have different contents: xx.svg Is there anything we can do to avoid/fix this? Much appreciated!
kerem 2026-03-03 14:39:04 +03:00
  • closed this issue
  • added the
    3rd-party
    label
Author
Owner

@NotTsunami commented on GitHub (Aug 20, 2023):

Would you be able to provide a minimal reproducible repository? I suspect esbuild is trying to place 1x1 and 4x3 resolutions in the same output folder.

<!-- gh-comment-id:1685151636 --> @NotTsunami commented on GitHub (Aug 20, 2023): Would you be able to provide a minimal reproducible repository? I suspect esbuild is trying to place 1x1 and 4x3 resolutions in the same output folder.
Author
Owner

@joewIST commented on GitHub (Aug 21, 2023):

I'm afraid I can't provide a repository, but I can refer to some of the features of the build:

We are using:
"flag-icons": "6.9.5",

The Angular build executor is using:
"executor": "@angular-devkit/build-angular:browser-esbuild",

The ts.config.base.json is using:
"target": "ESNext",
"module": "ESNext"

And you are correct: ESBuild seems to be putting both resolutions in the same folder, but they have identical names.

I found a workaround which was to put:

script in the index.html, but this is sub-optimal IMO as it means we would need to update the package in both package.json and index.html.

Any help would be greatly appreciated!

<!-- gh-comment-id:1685783024 --> @joewIST commented on GitHub (Aug 21, 2023): I'm afraid I can't provide a repository, but I can refer to some of the features of the build: We are using: "flag-icons": "6.9.5", The Angular build executor is using: "executor": "@angular-devkit/build-angular:browser-esbuild", The ts.config.base.json is using: "target": "ESNext", "module": "ESNext" And you are correct: ESBuild seems to be putting both resolutions in the same folder, but they have identical names. I found a workaround which was to put: <link rel="stylesheet" href="https://cdn.jsdelivr.net/gh/lipis/flag-icons@6.9.5/css/flag-icons.min.css" /> script in the index.html, but this is sub-optimal IMO as it means we would need to update the package in both package.json and index.html. Any help would be greatly appreciated!
Author
Owner

@joewIST commented on GitHub (Aug 31, 2023):

Hi, is this something that is fixable or should we look towards alternative options?

<!-- gh-comment-id:1700492116 --> @joewIST commented on GitHub (Aug 31, 2023): Hi, is this something that is fixable or should we look towards alternative options?
Author
Owner

@w0wka91 commented on GitHub (Oct 20, 2023):

Any solution for this issue?

<!-- gh-comment-id:1772416395 --> @w0wka91 commented on GitHub (Oct 20, 2023): Any solution for this issue?
Author
Owner

@joewIST commented on GitHub (Oct 20, 2023):

I have still not found a solution and therefore we cannot use esbuild in our project yet.

<!-- gh-comment-id:1772513424 --> @joewIST commented on GitHub (Oct 20, 2023): I have still not found a solution and therefore we cannot use esbuild in our project yet.
Author
Owner

@crodriguezdominguez commented on GitHub (Nov 8, 2023):

Same problem here. I'm using version 6.14.0.

<!-- gh-comment-id:1802118793 --> @crodriguezdominguez commented on GitHub (Nov 8, 2023): Same problem here. I'm using version 6.14.0.
Author
Owner

@ssougnez commented on GitHub (Nov 9, 2023):

As previous posts indicated, the issue is this:

.fi-gw {
  background-image: url(../flags/4x3/gw.svg);
}
.fi-gw.fis {
  background-image: url(../flags/1x1/gw.svg);
}

Both file will be copied in the same directory with the same name.
A solution would be to modify the CSS of flag-icons to:

.fi-gw {
  background-image: url(../flags/4x3/gw-4x3.svg);
}
.fi-gw.fis {
  background-image: url(../flags/1x1/gw-1x1.svg);
}

This way, image names won't collide anymore.

<!-- gh-comment-id:1803560223 --> @ssougnez commented on GitHub (Nov 9, 2023): As previous posts indicated, the issue is this: ``` .fi-gw { background-image: url(../flags/4x3/gw.svg); } .fi-gw.fis { background-image: url(../flags/1x1/gw.svg); } ``` Both file will be copied in the same directory with the same name. A solution would be to modify the CSS of flag-icons to: ``` .fi-gw { background-image: url(../flags/4x3/gw-4x3.svg); } .fi-gw.fis { background-image: url(../flags/1x1/gw-1x1.svg); } ``` This way, image names won't collide anymore.
Author
Owner

@timothee-dhenain-zenika commented on GitHub (Nov 10, 2023):

Having the same issue here, we tried to upgrade our project with the Angular latest release (v17) , but the application bundle generation fails with the new ESBuild

I don't have a minimal reproducible repository, but on our side we have this configuration:

package.json

"architect": {
        "build": {
          "builder": "@angular-devkit/build-angular:application",
          "options": {
            "styles": ["src/styles.scss", "node_modules/flag-icons/sass/flag-icons.scss"],

Including these styles in the build process means that they will be compiled and bundled with the rest of the application's assets when we build the Angular project. If you need, some further documentation is provided here

As a upgrade-blocking issue, if you could fix it that'd be great!

<!-- gh-comment-id:1806073320 --> @timothee-dhenain-zenika commented on GitHub (Nov 10, 2023): Having the same issue here, we tried to upgrade our project with the [Angular latest release (v17)](https://blog.angular.io/announcing-angular-dev-1e1205fa3039) , but the application bundle generation fails with the new [ESBuild](https://angular.dev/tools/cli/esbuild#using-the-application-builder) I don't have a minimal reproducible repository, but on our side we have this configuration: _package.json_ ``` "architect": { "build": { "builder": "@angular-devkit/build-angular:application", "options": { "styles": ["src/styles.scss", "node_modules/flag-icons/sass/flag-icons.scss"], ``` Including these styles in the build process means that they will be compiled and bundled with the rest of the application's assets when we build the Angular project. If you need, some further documentation is provided [here](https://stackoverflow.com/questions/37484937/angular-cli-how-to-add-global-styles) As a upgrade-blocking issue, if you could fix it that'd be great!
Author
Owner

@w0wka91 commented on GitHub (Nov 11, 2023):

You can fix the issue by adding outputHashing to the development configuration:

          "configurations": {
            "production": {
              "budgets": [
                {
                  "type": "initial",
                  "maximumWarning": "500kb",
                  "maximumError": "1mb"
                },
                {
                  "type": "anyComponentStyle",
                  "maximumWarning": "2kb",
                  "maximumError": "4kb"
                }
              ],
              "outputHashing": "all"
            },
            "development": {
              "optimization": false,
              "extractLicenses": false,
              "sourceMap": true,
              "outputHashing": "media"
            }
          }
<!-- gh-comment-id:1806814863 --> @w0wka91 commented on GitHub (Nov 11, 2023): You can fix the issue by adding outputHashing to the development configuration: ```json "configurations": { "production": { "budgets": [ { "type": "initial", "maximumWarning": "500kb", "maximumError": "1mb" }, { "type": "anyComponentStyle", "maximumWarning": "2kb", "maximumError": "4kb" } ], "outputHashing": "all" }, "development": { "optimization": false, "extractLicenses": false, "sourceMap": true, "outputHashing": "media" } } ```
Author
Owner

@ssougnez commented on GitHub (Nov 11, 2023):

Well, know I know what is the purpose of this outputHashing stuff.

Thanks a lot for the tip, works like a charm

<!-- gh-comment-id:1806823902 --> @ssougnez commented on GitHub (Nov 11, 2023): Well, know I know what is the purpose of this outputHashing stuff. Thanks a lot for the tip, works like a charm
Author
Owner

@joewIST commented on GitHub (Nov 13, 2023):

This hasn't worked for us, we still get the same errors. This is now blocking us from updating to Angular v.17.

<!-- gh-comment-id:1807802111 --> @joewIST commented on GitHub (Nov 13, 2023): This hasn't worked for us, we still get the same errors. This is now blocking us from updating to Angular v.17.
Author
Owner

@ssougnez commented on GitHub (Nov 13, 2023):

Ensure that you apply it to the correct configuration.
I was stuck with migrating to ng17 and this worked for me.

<!-- gh-comment-id:1808057553 --> @ssougnez commented on GitHub (Nov 13, 2023): Ensure that you apply it to the correct configuration. I was stuck with migrating to ng17 and this worked for me.
Author
Owner

@joewIST commented on GitHub (Nov 13, 2023):

I have copied the above and still get the same issues...

<!-- gh-comment-id:1808059966 --> @joewIST commented on GitHub (Nov 13, 2023): I have copied the above and still get the same issues...
Author
Owner

@ssougnez commented on GitHub (Nov 13, 2023):

can you maybe post your whole angular.json in here (not doubting you, just trying to find out the difference with mine to help you)?

<!-- gh-comment-id:1808062696 --> @ssougnez commented on GitHub (Nov 13, 2023): can you maybe post your whole angular.json in here (not doubting you, just trying to find out the difference with mine to help you)?
Author
Owner

@joewIST commented on GitHub (Nov 13, 2023):

"options": {
"baseHref": "/",
"outputPath": "dist/apps/XXXX/browser/browser",
"index": "apps/XXXX/src/index.html",
"main": "apps/XXXX/src/main.ts",
"tsConfig": "apps/XXXX/tsconfig.app.json",
"polyfills": "apps/XXXX/src/polyfills.ts",
"assets": [
"apps/XXXX/src/assets/icon",
"apps/XXXX/src/favicon.ico",
"apps/XXXX/src/manifest.webmanifest",
{
"input": "apps/XXXX/src/assets/config/development",
"glob": ".json",
"output": "assets/config"
},
{
"input": "libs/shared/ui/assets",
"glob": "**/
",
"output": "assets"
}
],
"styles": [
"node_modules/@angular/material/prebuilt-themes/deeppurple-amber.css",
"node_modules/katex/dist/katex.css",
"node_modules/flag-icons/css/flag-icons.min.css",
"node_modules/intro.js/introjs.css",
"apps/XXXX/src/styles.scss"
],
"stylePreprocessorOptions": {
"includePaths": ["apps/XXXX/src/styles"]
},
"scripts": ["node_modules/webfontloader/webfontloader.js", "node_modules/intro.js/intro.js"],
"allowedCommonJsDependencies": ["dayjs", "katex", "extract-math"],
"inlineStyleLanguage": "scss",
"customWebpackConfig": {
"path": "./webpack.config.js"
}
},
"configurations": {
"defaultConfiguration": "development",
"development": {
"buildOptimizer": false,
"optimization": false,
"vendorChunk": true,
"extractLicenses": false,
"sourceMap": true,
"namedChunks": true
},
"production": {
"serviceWorker": true,
"ngswConfigPath": "apps/XXXX/ngsw-config.json",
"assets": [
"apps/XXXX/src/assets/icon",
"apps/XXXX/src/favicon.ico",
"apps/XXXX/src/manifest.webmanifest",
{
"input": "apps/XXXX/src/assets/config/production",
"glob": ".json",
"output": "assets/config"
},
{
"input": "libs/shared/ui/assets",
"glob": "**/
",
"output": "assets"
}
],
"sourceMap": {
"scripts": true
},
"optimization": true,
"outputHashing": "all",
"namedChunks": false,
"extractLicenses": true,
"vendorChunk": false,
"buildOptimizer": true,
"fileReplacements": [
{
"replace": "apps/XXXX/src/environments/environment.ts",
"with": "apps/XXXX/src/environments/environment.prod.ts"
}
]
}
}

<!-- gh-comment-id:1808091081 --> @joewIST commented on GitHub (Nov 13, 2023): "options": { "baseHref": "/", "outputPath": "dist/apps/XXXX/browser/browser", "index": "apps/XXXX/src/index.html", "main": "apps/XXXX/src/main.ts", "tsConfig": "apps/XXXX/tsconfig.app.json", "polyfills": "apps/XXXX/src/polyfills.ts", "assets": [ "apps/XXXX/src/assets/icon", "apps/XXXX/src/favicon.ico", "apps/XXXX/src/manifest.webmanifest", { "input": "apps/XXXX/src/assets/config/development", "glob": "*.json", "output": "assets/config" }, { "input": "libs/shared/ui/assets", "glob": "**/*", "output": "assets" } ], "styles": [ "node_modules/@angular/material/prebuilt-themes/deeppurple-amber.css", "node_modules/katex/dist/katex.css", "node_modules/flag-icons/css/flag-icons.min.css", "node_modules/intro.js/introjs.css", "apps/XXXX/src/styles.scss" ], "stylePreprocessorOptions": { "includePaths": ["apps/XXXX/src/styles"] }, "scripts": ["node_modules/webfontloader/webfontloader.js", "node_modules/intro.js/intro.js"], "allowedCommonJsDependencies": ["dayjs", "katex", "extract-math"], "inlineStyleLanguage": "scss", "customWebpackConfig": { "path": "./webpack.config.js" } }, "configurations": { "defaultConfiguration": "development", "development": { "buildOptimizer": false, "optimization": false, "vendorChunk": true, "extractLicenses": false, "sourceMap": true, "namedChunks": true }, "production": { "serviceWorker": true, "ngswConfigPath": "apps/XXXX/ngsw-config.json", "assets": [ "apps/XXXX/src/assets/icon", "apps/XXXX/src/favicon.ico", "apps/XXXX/src/manifest.webmanifest", { "input": "apps/XXXX/src/assets/config/production", "glob": "*.json", "output": "assets/config" }, { "input": "libs/shared/ui/assets", "glob": "**/*", "output": "assets" } ], "sourceMap": { "scripts": true }, "optimization": true, "outputHashing": "all", "namedChunks": false, "extractLicenses": true, "vendorChunk": false, "buildOptimizer": true, "fileReplacements": [ { "replace": "apps/XXXX/src/environments/environment.ts", "with": "apps/XXXX/src/environments/environment.prod.ts" } ] } }
Author
Owner

@w0wka91 commented on GitHub (Nov 13, 2023):

You need to add outputHashing to your development configuration:

"options": {
"baseHref": "/",
"outputPath": "dist/apps/XXXX/browser/browser",
"index": "apps/XXXX/src/index.html",
"main": "apps/XXXX/src/main.ts",
"tsConfig": "apps/XXXX/tsconfig.app.json",
"polyfills": "apps/XXXX/src/polyfills.ts",
"assets": [
"apps/XXXX/src/assets/icon",
"apps/XXXX/src/favicon.ico",
"apps/XXXX/src/manifest.webmanifest",
{
"input": "apps/XXXX/src/assets/config/development",
"glob": ".json",
"output": "assets/config"
},
{
"input": "libs/shared/ui/assets",
"glob": "**/",
"output": "assets"
}
],
"styles": [
"node_modules/@angular/material/prebuilt-themes/deeppurple-amber.css",
"node_modules/katex/dist/katex.css",
"node_modules/flag-icons/css/flag-icons.min.css",
"node_modules/intro.js/introjs.css",
"apps/XXXX/src/styles.scss"
],
"stylePreprocessorOptions": {
"includePaths": ["apps/XXXX/src/styles"]
},
"scripts": ["node_modules/webfontloader/webfontloader.js", "node_modules/intro.js/intro.js"],
"allowedCommonJsDependencies": ["dayjs", "katex", "extract-math"],
"inlineStyleLanguage": "scss",
"customWebpackConfig": {
"path": "./webpack.config.js"
}
},
"configurations": {
"defaultConfiguration": "development",
"development": {
"outputHashing": "media",
"buildOptimizer": false,
"optimization": false,
"vendorChunk": true,
"extractLicenses": false,
"sourceMap": true,
"namedChunks": true
},
"production": {
"serviceWorker": true,
"ngswConfigPath": "apps/XXXX/ngsw-config.json",
"assets": [
"apps/XXXX/src/assets/icon",
"apps/XXXX/src/favicon.ico",
"apps/XXXX/src/manifest.webmanifest",
{
"input": "apps/XXXX/src/assets/config/production",
"glob": ".json",
"output": "assets/config"
},
{
"input": "libs/shared/ui/assets",
"glob": "**/",
"output": "assets"
}
],
"sourceMap": {
"scripts": true
},
"optimization": true,
"outputHashing": "all",
"namedChunks": false,
"extractLicenses": true,
"vendorChunk": false,
"buildOptimizer": true,
"fileReplacements": [
{
"replace": "apps/XXXX/src/environments/environment.ts",
"with": "apps/XXXX/src/environments/environment.prod.ts"
}
]
}
}
<!-- gh-comment-id:1808095274 --> @w0wka91 commented on GitHub (Nov 13, 2023): You need to add outputHashing to your development configuration: ```json "options": { "baseHref": "/", "outputPath": "dist/apps/XXXX/browser/browser", "index": "apps/XXXX/src/index.html", "main": "apps/XXXX/src/main.ts", "tsConfig": "apps/XXXX/tsconfig.app.json", "polyfills": "apps/XXXX/src/polyfills.ts", "assets": [ "apps/XXXX/src/assets/icon", "apps/XXXX/src/favicon.ico", "apps/XXXX/src/manifest.webmanifest", { "input": "apps/XXXX/src/assets/config/development", "glob": ".json", "output": "assets/config" }, { "input": "libs/shared/ui/assets", "glob": "**/", "output": "assets" } ], "styles": [ "node_modules/@angular/material/prebuilt-themes/deeppurple-amber.css", "node_modules/katex/dist/katex.css", "node_modules/flag-icons/css/flag-icons.min.css", "node_modules/intro.js/introjs.css", "apps/XXXX/src/styles.scss" ], "stylePreprocessorOptions": { "includePaths": ["apps/XXXX/src/styles"] }, "scripts": ["node_modules/webfontloader/webfontloader.js", "node_modules/intro.js/intro.js"], "allowedCommonJsDependencies": ["dayjs", "katex", "extract-math"], "inlineStyleLanguage": "scss", "customWebpackConfig": { "path": "./webpack.config.js" } }, "configurations": { "defaultConfiguration": "development", "development": { "outputHashing": "media", "buildOptimizer": false, "optimization": false, "vendorChunk": true, "extractLicenses": false, "sourceMap": true, "namedChunks": true }, "production": { "serviceWorker": true, "ngswConfigPath": "apps/XXXX/ngsw-config.json", "assets": [ "apps/XXXX/src/assets/icon", "apps/XXXX/src/favicon.ico", "apps/XXXX/src/manifest.webmanifest", { "input": "apps/XXXX/src/assets/config/production", "glob": ".json", "output": "assets/config" }, { "input": "libs/shared/ui/assets", "glob": "**/", "output": "assets" } ], "sourceMap": { "scripts": true }, "optimization": true, "outputHashing": "all", "namedChunks": false, "extractLicenses": true, "vendorChunk": false, "buildOptimizer": true, "fileReplacements": [ { "replace": "apps/XXXX/src/environments/environment.ts", "with": "apps/XXXX/src/environments/environment.prod.ts" } ] } } ```
Author
Owner

@joewIST commented on GitHub (Nov 13, 2023):

Ah sorry I'd just removed that while reverting my changes. It still doesn't work so I will need to continue using webpack browser

<!-- gh-comment-id:1808097475 --> @joewIST commented on GitHub (Nov 13, 2023): Ah sorry I'd just removed that while reverting my changes. It still doesn't work so I will need to continue using webpack browser
Author
Owner

@ssougnez commented on GitHub (Nov 13, 2023):

When I changed the build to application, I had to change this line:

"main": "apps/XXXX/src/main.ts",

to

"browser": "apps/XXXX/src/main.ts",

but I see that it's not the case for you.
Can you try ? And ensure that you're using the "application" builder?

<!-- gh-comment-id:1808311292 --> @ssougnez commented on GitHub (Nov 13, 2023): When I changed the build to application, I had to change this line: `"main": "apps/XXXX/src/main.ts",` to `"browser": "apps/XXXX/src/main.ts",` but I see that it's not the case for you. Can you try ? And ensure that you're using the "application" builder?
Author
Owner

@joewIST commented on GitHub (Nov 13, 2023):

Yes I already tried that as well, no luck...

<!-- gh-comment-id:1808336951 --> @joewIST commented on GitHub (Nov 13, 2023): Yes I already tried that as well, no luck...
Author
Owner

@joewIST commented on GitHub (Nov 16, 2023):

Is this something this library is planning on supporting? @lipis

<!-- gh-comment-id:1813976803 --> @joewIST commented on GitHub (Nov 16, 2023): Is this something this library is planning on supporting? @lipis
Author
Owner

@lipis commented on GitHub (Nov 16, 2023):

@joewIST What exactly should we do?

<!-- gh-comment-id:1814649105 --> @lipis commented on GitHub (Nov 16, 2023): @joewIST What exactly should we do?
Author
Owner

@ssougnez commented on GitHub (Nov 16, 2023):

Renaming the files as I suggested might be a viable solution.

<!-- gh-comment-id:1814673231 --> @ssougnez commented on GitHub (Nov 16, 2023): Renaming the files as I suggested might be a viable solution.
Author
Owner

@lipis commented on GitHub (Nov 16, 2023):

Renaming the files? Haven't really followed closely the conversation.. all we offer in this library is bunch of files and the css for it.. there is no .ts or anything like that...

<!-- gh-comment-id:1814688229 --> @lipis commented on GitHub (Nov 16, 2023): Renaming the files? Haven't really followed closely the conversation.. all we offer in this library is bunch of files and the css for it.. there is no `.ts` or anything like that...
Author
Owner

@ssougnez commented on GitHub (Nov 16, 2023):

The issue is that when using esbuilder, all files end up in the same directory and as files in 1x1 have the same names as the ones in 4x3, it creates an override issue.

There is a possibility to configure esbuilder to hash the names but it seems that it does not work for everyone.

Therefore, a solution would be to rename files in 1x1 with the suffix "-1x1" and same for "4x3".

<!-- gh-comment-id:1814716753 --> @ssougnez commented on GitHub (Nov 16, 2023): The issue is that when using esbuilder, all files end up in the same directory and as files in 1x1 have the same names as the ones in 4x3, it creates an override issue. There is a possibility to configure esbuilder to hash the names but it seems that it does not work for everyone. Therefore, a solution would be to rename files in 1x1 with the suffix "-1x1" and same for "4x3".
Author
Owner

@joewIST commented on GitHub (Nov 16, 2023):

Yes the duplicate file issue is basically blocking us from upgrading from esbuild, and therefore from fully taking advantage of Angular v.17. I have tried outputHashing but it's not working...

<!-- gh-comment-id:1814739486 --> @joewIST commented on GitHub (Nov 16, 2023): Yes the duplicate file issue is basically blocking us from upgrading from esbuild, and therefore from fully taking advantage of Angular v.17. I have tried outputHashing but it's not working...
Author
Owner

@jonaaix commented on GitHub (Nov 16, 2023):

While enabling outputHashing works for our application, it still has to be considered as workaround since it can impact the build performance in dev env, especially for big enterprise apps.

More about esbuild asset hashing:
https://esbuild.github.io/api/#asset-names

Following this, there is no reason that the duplicate file issue of this library remains with the hashing enabled. You should recheck the esbuild configuration in your project.
https://angular.io/guide/esbuild
https://nx.dev/nx-api/esbuild

That being said, the main issue is that esbuild in general conflicts with the architecture of this library. Its not an Angular issue.

<!-- gh-comment-id:1815004656 --> @jonaaix commented on GitHub (Nov 16, 2023): While enabling `outputHashing` works for our application, it still has to be considered as workaround since it can impact the build performance in dev env, especially for big enterprise apps. More about esbuild asset hashing: https://esbuild.github.io/api/#asset-names Following this, there is no reason that the duplicate file issue of this library remains with the hashing enabled. You should recheck the esbuild configuration in your project. https://angular.io/guide/esbuild https://nx.dev/nx-api/esbuild That being said, the main issue is that esbuild in general conflicts with the architecture of this library. Its not an Angular issue.
Author
Owner

@NotTsunami commented on GitHub (Nov 16, 2023):

The issue is that when using esbuilder, all files end up in the same directory and as files in 1x1 have the same names as the ones in 4x3, it creates an override issue.

There is a possibility to configure esbuilder to hash the names but it seems that it does not work for everyone.

Therefore, a solution would be to rename files in 1x1 with the suffix "-1x1" and same for "4x3".

Keep in mind the renaming for the files will be a breaking change as well. If you'd like, I can provide a batch script in the project root that appends the -1x1 and -4x3 to the respective flags (and maybe one to perhaps undo it?), and then you should be able to invoke that from your package.json via npm explore in your build steps. Does that sound like an appropriate response in the case where outputHashing isn't the right solution? I'm not opposed to other solutions as well, but I'm a little hesitant to just rename flags when that's a breaking change.

<!-- gh-comment-id:1815509052 --> @NotTsunami commented on GitHub (Nov 16, 2023): > The issue is that when using esbuilder, all files end up in the same directory and as files in 1x1 have the same names as the ones in 4x3, it creates an override issue. > > There is a possibility to configure esbuilder to hash the names but it seems that it does not work for everyone. > > Therefore, a solution would be to rename files in 1x1 with the suffix "-1x1" and same for "4x3". Keep in mind the renaming for the files will be a breaking change as well. If you'd like, I can provide a batch script in the project root that appends the -1x1 and -4x3 to the respective flags (and maybe one to perhaps undo it?), and then you should be able to invoke that from your package.json via `npm explore` in your build steps. Does that sound like an appropriate response in the case where outputHashing isn't the right solution? I'm not opposed to other solutions as well, but I'm a little hesitant to just rename flags when that's a breaking change.
Author
Owner

@ssougnez commented on GitHub (Nov 17, 2023):

To be honest, the outputHash works with me, so it does not matter.

However, people are not supposed to use images directly, are they? So if you adapt the scss to the new image names, why would it be a breaking change?

<!-- gh-comment-id:1815884962 --> @ssougnez commented on GitHub (Nov 17, 2023): To be honest, the outputHash works with me, so it does not matter. However, people are not supposed to use images directly, are they? So if you adapt the scss to the new image names, why would it be a breaking change?
Author
Owner

@joewIST commented on GitHub (Nov 17, 2023):

OK I managed to get outputHashing to work, but I needed to put it in the "options" part of the build configuration, not in the "configurations" -> "development" section. Not sure why but that works. We are still blocked from fully integrating esbuild due to our reliance on sentry (which needs a webpack plugin; no support for esbuild plugins yet without custom implementation), but at least I know I can do a workaround for this library. Thanks @ssougnez !

<!-- gh-comment-id:1815943466 --> @joewIST commented on GitHub (Nov 17, 2023): OK I managed to get outputHashing to work, but I needed to put it in the "options" part of the build configuration, not in the "configurations" -> "development" section. Not sure why but that works. We are still blocked from fully integrating esbuild due to our reliance on sentry (which needs a webpack plugin; no support for esbuild plugins yet without custom implementation), but at least I know I can do a workaround for this library. Thanks @ssougnez !
Author
Owner

@lipis commented on GitHub (Nov 17, 2023):

@ssougnez not many people are using the css at all but directly the images (including me in some projects).. the css is an add on.. the main product is the flag icons as the name suggests :)

<!-- gh-comment-id:1816799690 --> @lipis commented on GitHub (Nov 17, 2023): @ssougnez not many people are using the css at all but directly the images (including me in some projects).. the css is an add on.. the main product is the flag icons as the name suggests :)
Author
Owner

@ssougnez commented on GitHub (Nov 17, 2023):

Yeah sorry, I'm still on the old one which was flags-icon-css or something wasn't it? Ok then, I understand the breaking change :-)

Now, it seems that the one who had an issue with outputHash fixed it so maybe the issue is no longer relevant.

<!-- gh-comment-id:1816827225 --> @ssougnez commented on GitHub (Nov 17, 2023): Yeah sorry, I'm still on the old one which was flags-icon-css or something wasn't it? Ok then, I understand the breaking change :-) Now, it seems that the one who had an issue with outputHash fixed it so maybe the issue is no longer relevant.
Author
Owner

@NotTsunami commented on GitHub (Nov 17, 2023):

At the very least, I'll push a change to the README.md referencing this issue for ESBuild usage. If there's any desire for a script to rename the flags on the fly, I can add that on-demand.

<!-- gh-comment-id:1816849568 --> @NotTsunami commented on GitHub (Nov 17, 2023): At the very least, I'll push a change to the README.md referencing this issue for ESBuild usage. If there's any desire for a script to rename the flags on the fly, I can add that on-demand.
Author
Owner

@lipis commented on GitHub (Nov 17, 2023):

I'm down on updating the Readme and adding a script for those users if needed...

<!-- gh-comment-id:1816864126 --> @lipis commented on GitHub (Nov 17, 2023): I'm down on updating the Readme and adding a script for those users if needed...
Author
Owner

@tsteuwer-accesso commented on GitHub (Nov 30, 2023):

I personally dont like hashing images if they're not changing. Because that would mean that browsers will need to redownload them everytime a new build is released. Is it possible for us to just rename the file or add the files so that this isn't an issue with bundlers?

<!-- gh-comment-id:1834138299 --> @tsteuwer-accesso commented on GitHub (Nov 30, 2023): I personally dont like hashing images if they're not changing. Because that would mean that browsers will need to redownload them everytime a new build is released. Is it possible for us to just rename the file or add the files so that this isn't an issue with bundlers?
Author
Owner

@NotTsunami commented on GitHub (Dec 5, 2023):

I personally dont like hashing images if they're not changing. Because that would mean that browsers will need to redownload them everytime a new build is released. Is it possible for us to just rename the file or add the files so that this isn't an issue with bundlers?

As previously mentioned, the reason I'm hesitant to push a change like that is that there are several packages/libraries/applications that link directly to the flags inside the repo (which isn't really encouraged, but it is fairly common), so this can break resolution if we suddenly change with no advance notice.

I guess ultimately, we should aim to:

  • Immediately add comment to README.md about usage of outputHashing as an immediate fix, but also provide a script that can be run as a build step to rename flags for cases where outputHashing is either not desired or insufficient.
  • In the very near future, choose a date to rename flags to xx-1x1.svg and xx-4x3.svg and then add a warning to the top of the README.md regarding when this change will occur.
  • In the longer term, enact on the name change.

That would be the path of least resistance. Naturally, there will still be people that won't read this and we would run into issues, but that's unavoidable. I've noticed from working on JavaScript projects that sometimes when you pull packages they include notices or comments, like depcrecation warnings for renamed packages, etc. I wonder if we can make use of that to provide additional notice regarding renaming the flags if we end up choosing to do so. Thoughts? @lipis

Also updated my public facing email, feel free to bring this over to email as well: contact@tylerd.dev

<!-- gh-comment-id:1841317958 --> @NotTsunami commented on GitHub (Dec 5, 2023): > I personally dont like hashing images if they're not changing. Because that would mean that browsers will need to redownload them everytime a new build is released. Is it possible for us to just rename the file or add the files so that this isn't an issue with bundlers? As previously mentioned, the reason I'm hesitant to push a change like that is that there are several packages/libraries/applications that link directly to the flags inside the repo (which isn't really encouraged, but it is fairly common), so this can break resolution if we suddenly change with no advance notice. I guess ultimately, we should aim to: - Immediately add comment to README.md about usage of outputHashing as an immediate fix, but also provide a script that can be run as a build step to rename flags for cases where outputHashing is either not desired or insufficient. - In the very near future, choose a date to rename flags to `xx-1x1.svg` and `xx-4x3.svg` and then add a warning to the top of the README.md regarding when this change will occur. - In the longer term, enact on the name change. That would be the path of least resistance. Naturally, there will still be people that won't read this and we would run into issues, but that's unavoidable. I've noticed from working on JavaScript projects that sometimes when you pull packages they include notices or comments, like depcrecation warnings for renamed packages, etc. I wonder if we can make use of that to provide additional notice regarding renaming the flags if we end up choosing to do so. Thoughts? @lipis Also updated my public facing email, feel free to bring this over to email as well: contact@tylerd.dev
Author
Owner

@ssougnez commented on GitHub (Dec 5, 2023):

To be honest, that's what major versions are for... No one should upgrade a library to a new major version without paying attention to the breaking changes.

If you include a clear explanation in the readme about it, it should be enough.

<!-- gh-comment-id:1841620308 --> @ssougnez commented on GitHub (Dec 5, 2023): To be honest, that's what major versions are for... No one should upgrade a library to a new major version without paying attention to the breaking changes. If you include a clear explanation in the readme about it, it should be enough.
Author
Owner

@tsteuwer-accesso commented on GitHub (Dec 6, 2023):

I agree with @ssougnez . The change should just be a move to new file names and make it a new major version.

<!-- gh-comment-id:1842790176 --> @tsteuwer-accesso commented on GitHub (Dec 6, 2023): I agree with @ssougnez . The change should just be a move to new file names and make it a new major version.
Author
Owner

@lipis commented on GitHub (Dec 6, 2023):

@NotTsunami Let's agree on the final naming and we can do it eventually.. yes no need to announce anything.. new major version with breaking changes.. who ever is using the website for showing the flags I don't care to be honest.. it's not fair anyway :)

<!-- gh-comment-id:1843550428 --> @lipis commented on GitHub (Dec 6, 2023): @NotTsunami Let's agree on the final naming and we can do it eventually.. yes no need to announce anything.. new major version with breaking changes.. who ever is using the website for showing the flags I don't care to be honest.. it's not fair anyway :)
Author
Owner

@nkosi23 commented on GitHub (Jan 5, 2024):

i've just been beaten up by this after switching to esbuild

<!-- gh-comment-id:1878586704 --> @nkosi23 commented on GitHub (Jan 5, 2024): i've just been beaten up by this after switching to esbuild
Author
Owner

@kristofdho commented on GitHub (Apr 3, 2024):

Still can't get it to work with "builder": "@angular-devkit/build-angular:browser-esbuild", and outputHashing set in various different places.
Any idea when a next major release for this would be planned?

<!-- gh-comment-id:2034072773 --> @kristofdho commented on GitHub (Apr 3, 2024): Still can't get it to work with `"builder": "@angular-devkit/build-angular:browser-esbuild",` and `outputHashing` set in various different places. Any idea when a next major release for this would be planned?
Author
Owner

@Ostabo commented on GitHub (Apr 11, 2024):

I made a fork as a temporary solution for people like me who can't wait:
repo: Ostabo/flag-icons - npm: @ostabo/flag-icons
File names are changed like this: flags/1x1/ad.svg -> flags/1x1-ad.svg

Beware tho that this is no drop in replacement as imports need to change

<!-- gh-comment-id:2049833373 --> @Ostabo commented on GitHub (Apr 11, 2024): I made a fork as a temporary solution for people like me who can't wait: repo: [Ostabo/flag-icons](https://github.com/Ostabo/flag-icons) - npm: [@ostabo/flag-icons](https://www.npmjs.com/package/@ostabo/flag-icons) File names are changed like this: `flags/1x1/ad.svg` -> `flags/1x1-ad.svg` Beware tho that this is no drop in replacement as imports need to change
Author
Owner

@olafurfannsker commented on GitHub (Apr 17, 2024):

The outputHashing worked like a charm with flag-icons v: 7.2.1 and angular v: 17.3.5...

<!-- gh-comment-id:2062596744 --> @olafurfannsker commented on GitHub (Apr 17, 2024): The outputHashing worked like a charm with flag-icons v: 7.2.1 and angular v: 17.3.5...
Author
Owner

@itworksafisher commented on GitHub (Nov 19, 2024):

Production builds should really use output hashing none though. Output hashing is all about cache busting. Setting it to media is going to add a hash to all the flag icons, i.e. ad.svg turns in to something like ad.09812309a8sd09.svg, which is how this setting fixes the issue with two files with same name. They won't be the same anymore because they will have different hashes. But this will apply to ALL media, not just the flag icons. The flag icons are small, so this isn't a concern, but for any media which is large, you will be forcing the browser to redownload it with each new build, even when it hasn't changed. This doesn't seem like a good solution overall.

<!-- gh-comment-id:2484806212 --> @itworksafisher commented on GitHub (Nov 19, 2024): Production builds should really use output hashing none though. Output hashing is all about cache busting. Setting it to media is going to add a hash to all the flag icons, i.e. ad.svg turns in to something like ad.09812309a8sd09.svg, which is how this setting fixes the issue with two files with same name. They won't be the same anymore because they will have different hashes. But this will apply to ALL media, not just the flag icons. The flag icons are small, so this isn't a concern, but for any media which is large, you will be forcing the browser to redownload it with each new build, even when it hasn't changed. This doesn't seem like a good solution overall.
Author
Owner

@joewIST commented on GitHub (Nov 19, 2024):

Is this something that @lipis would consider updating any time soon?

<!-- gh-comment-id:2485020998 --> @joewIST commented on GitHub (Nov 19, 2024): Is this something that @lipis would consider updating any time soon?
Author
Owner

@itworksafisher commented on GitHub (Nov 21, 2024):

A good example from my project is that we host font awesome pro fonts, which can be upward of 1.4MB for the ttfs (woff2 is much smaller). We definitely would want that to be cached if possible, but using outputHashing media prevents that.

<!-- gh-comment-id:2492001914 --> @itworksafisher commented on GitHub (Nov 21, 2024): A good example from my project is that we host font awesome pro fonts, which can be upward of 1.4MB for the ttfs (woff2 is much smaller). We definitely would want that to be cached if possible, but using outputHashing media prevents that.
Author
Owner

@itworksafisher commented on GitHub (Dec 10, 2024):

I had a misunderstanding of output hashing. The hash is not random, but based on the content of the file itself, so if the file content does not change, the hash will not as well. Should be fine to use 'media' then or even 'all'. Would be nice if angular cli better documented this, but I could see that the hashes did not change across multiple builds.

<!-- gh-comment-id:2532701382 --> @itworksafisher commented on GitHub (Dec 10, 2024): I had a misunderstanding of output hashing. The hash is not random, but based on the content of the file itself, so if the file content does not change, the hash will not as well. Should be fine to use 'media' then or even 'all'. Would be nice if angular cli better documented this, but I could see that the hashes did not change across multiple builds.
Author
Owner

@joewIST commented on GitHub (Jan 17, 2025):

@lipis This has been closed as completed but I can't see the release that fixes it. Are you able to help?

<!-- gh-comment-id:2598794018 --> @joewIST commented on GitHub (Jan 17, 2025): @lipis This has been closed as completed but I can't see the release that fixes it. Are you able to help?
Author
Owner

@nkosi23 commented on GitHub (Feb 10, 2025):

Any update on this?

<!-- gh-comment-id:2648787263 --> @nkosi23 commented on GitHub (Feb 10, 2025): Any update on this?
Author
Owner

@oritpersik commented on GitHub (Feb 23, 2025):

Waiting for the right solution too.

<!-- gh-comment-id:2676669218 --> @oritpersik commented on GitHub (Feb 23, 2025): Waiting for the right solution too.
Author
Owner

@nkosi23 commented on GitHub (Feb 23, 2025):

@lipis it looks like this has been closed by mistake

<!-- gh-comment-id:2676678436 --> @nkosi23 commented on GitHub (Feb 23, 2025): @lipis it looks like this has been closed by mistake
Author
Owner

@nkosi23 commented on GitHub (Feb 23, 2025):

Okay, I think the present ticket was actually superseded by this one. Looking at the description on the linked page:

@import causes numerous problems, requiring Sass members to be manually namespaced to avoid conflicts, slowing down compilation when the same file is imported more than once, and making it very difficult for both humans and tools to tell where a given variable, mixin, or function comes from.
The module system fixes these problems and brings Sass’s modularity up to par with the best practices of other modern languages, but we can’t get the full benefits of it while @import remains in the language

It would have been nice to drop us a note here, so that people may for example have contributed to the PR currently pending.

<!-- gh-comment-id:2676736951 --> @nkosi23 commented on GitHub (Feb 23, 2025): Okay, I think the present ticket was actually superseded [by this one](https://github.com/lipis/flag-icons/issues/1324). Looking at the description on the linked page: > @import causes numerous problems, requiring Sass members to be manually namespaced to avoid conflicts, slowing down compilation when the same file is imported more than once, and making it very difficult for both humans and tools to tell where a given variable, mixin, or function comes from. The module system fixes these problems and brings Sass’s modularity up to par with the best practices of other modern languages, but we can’t get the full benefits of it while @import remains in the language It would have been nice to drop us a note here, so that people may for example have contributed to the PR currently pending.
Author
Owner

@siddarthagreddy commented on GitHub (Jun 16, 2025):

[ERROR] Two output files share the same path but have different contents: media/sh-ac.svg

I have above Error while I upgrade from Angular 17 to 18,
flag-icons has the svg with same name but they of different sizes

I tried every possible solution posted in this thread still the issue is same.

Need help!

<!-- gh-comment-id:2978126126 --> @siddarthagreddy commented on GitHub (Jun 16, 2025): [ERROR] Two output files share the same path but have different contents: media/sh-ac.svg I have above Error while I upgrade from Angular 17 to 18, flag-icons has the svg with same name but they of different sizes I tried every possible solution posted in this thread still the issue is same. Need help!
Author
Owner

@jens-muenker commented on GitHub (Jul 27, 2025):

I have the same issue. When will this be fixed @lipis?

<!-- gh-comment-id:3124495543 --> @jens-muenker commented on GitHub (Jul 27, 2025): I have the same issue. When will this be fixed @lipis?
Author
Owner

@Zonkodonko commented on GitHub (Aug 7, 2025):

Why was this issue closed? Seems like it has not been fixed

<!-- gh-comment-id:3163915552 --> @Zonkodonko commented on GitHub (Aug 7, 2025): Why was this issue closed? Seems like it has not been fixed
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/flag-icons#531
No description provided.