starred/flag-icons

Fork 0

mirror of https://github.com/lipis/flag-icons.git synced 2026-04-26 09:25:50 +03:00

[GH-ISSUE #885] Old flag urls return 404 #420

New issue

Closed

opened 2026-03-03 14:38:15 +03:00 by kerem · 7 comments

kerem commented

2026-03-03 14:38:15 +03:00

Owner

Originally created by @mastef on GitHub (Nov 2, 2021).
Original GitHub issue: https://github.com/lipis/flag-icons/issues/885

Hi - it seems that a popular react package called react-phone-number-input used your github page as the default cdn url in an earlier version: flagsPath:"https://lipis.github.io/flag-icon-css/flags/4x3/"

These urls are now returning 404, since the old format
https://lipis.github.io/flag-icon-css/flags/4x3/us.svg
changed to :
https://lipis.github.io/flag-icons/flags/4x3/us.svg
which forwards to
https://flagicons.lipis.dev/flags/4x3/us.svg

Is there any chance you could also auto-forward the old path https://lipis.github.io/flag-icon-css/flags/4x3/* to your new domain?

Originally created by @mastef on GitHub (Nov 2, 2021). Original GitHub issue: https://github.com/lipis/flag-icons/issues/885 Hi - it seems that a popular react package called `react-phone-number-input` used your github page as the default cdn url in an earlier version: `flagsPath:"https://lipis.github.io/flag-icon-css/flags/4x3/"` These urls are now returning 404, since the old format `https://lipis.github.io/flag-icon-css/flags/4x3/us.svg` changed to : `https://lipis.github.io/flag-icons/flags/4x3/us.svg` which forwards to `https://flagicons.lipis.dev/flags/4x3/us.svg` Is there any chance you could also auto-forward the old path `https://lipis.github.io/flag-icon-css/flags/4x3/*` to your new domain? Related issue on Gitlab: https://gitlab.com/catamphetamine/react-phone-number-input/-/issues/96

kerem closed this issue

2026-03-03 14:38:15 +03:00

kerem commented

2026-03-03 14:38:16 +03:00

Author

Owner

@lipis commented on GitHub (Nov 3, 2021):

Not really.. as components shouldn't really rely on these URLs.. I don't think it's fair :)

@lipis commented on GitHub (Nov 3, 2021): Not really.. as components shouldn't really rely on these URLs.. I don't think it's fair :)

kerem commented

2026-03-03 14:38:16 +03:00

Author

Owner

@lipis commented on GitHub (Nov 3, 2021):

Having said that.. I can't do much about it though.. it's a free world :)

@lipis commented on GitHub (Nov 3, 2021): Having said that.. I can't do much about it though.. it's a free world :)

kerem commented

2026-03-03 14:38:16 +03:00

Author

Owner

@mastef commented on GitHub (Nov 4, 2021):

@lipis I figured it may have been just a rewrite condition in github pages. If not possible - that's of course fine. I was surprised that they linked to your url.

Just going to be a bit of work to get deployed legacy apps to recompile, now that they have broken flags.

@mastef commented on GitHub (Nov 4, 2021): @lipis I figured it may have been just a rewrite condition in github pages. If not possible - that's of course fine. I was surprised that they linked to your url. Just going to be a bit of work to get deployed legacy apps to recompile, now that they have broken flags.

kerem commented

2026-03-03 14:38:16 +03:00

Author

Owner

@paul-vd commented on GitHub (Nov 10, 2021):

Would it not be better to version the flags, because this does cause outages on production environments.

@paul-vd commented on GitHub (Nov 10, 2021): Would it not be better to version the flags, because this does cause outages on production environments.

kerem commented

2026-03-03 14:38:17 +03:00

Author

Owner

@mastef commented on GitHub (Nov 10, 2021):

I agree. It was the choice of the popular library. I was not aware until
they started to 404.

Now have to figure out how to update the legacy apps.

@mastef commented on GitHub (Nov 10, 2021): I agree. It was the choice of the popular library. I was not aware until they started to 404. Now have to figure out how to update the legacy apps.

kerem commented

2026-03-03 14:38:17 +03:00

Author

Owner

@paul-vd commented on GitHub (Nov 10, 2021):

I agree. It was the choice of the popular library. I was not aware until they started to 404. Now have to figure out how to update the legacy apps.

I found an easy solution using patch-package.

You can download the old versions of flags https://github.com/lipis/flag-icons/releases, I used the 3.5.0.

You can then self-host those flags, or add them to the public folder of your project.

Then you can do a find and replace in your node_modules

- https://lipis.github.io/flag-icon-css/flags/4x3/
+ /path/to/flags/4x3/

Then run the patch package on the package(s) that uses the flags

$ npx patch-package react-phone-number-input

@paul-vd commented on GitHub (Nov 10, 2021): > I agree. It was the choice of the popular library. I was not aware until they started to 404. Now have to figure out how to update the legacy apps. I found an easy solution using `patch-package`. You can download the old versions of flags https://github.com/lipis/flag-icons/releases, I used the [3.5.0](https://github.com/lipis/flag-icons/releases/tag/3.5.0). You can then self-host those flags, or add them to the `public` folder of your project. Then you can do a find and replace in your `node_modules` ```diff - https://lipis.github.io/flag-icon-css/flags/4x3/ + /path/to/flags/4x3/ ``` Then run the patch package on the package(s) that uses the flags ```bash $ npx patch-package react-phone-number-input ```

kerem commented

2026-03-03 14:38:17 +03:00

Author

Owner

@mastef commented on GitHub (Nov 10, 2021):

I wouldn't recommend changing the content of node_modules.

For me the issue is rather that recompiling an older project is going to come up with a lot of other challenges, as dependencies are sometimes deleted, or there's incompatibilities with later node&npm versions etc.

If I have to recompile the project, then the solution is just to change the flagsPath parameter for the other package. I just dread having to recompile legacy node projects due to other reasons, so was hoping to avoid that by having the online link paths fixed by the original author. Alas, that's not going to happen.

@mastef commented on GitHub (Nov 10, 2021): I wouldn't recommend changing the content of node_modules. For me the issue is rather that recompiling an older project is going to come up with a lot of other challenges, as dependencies are sometimes deleted, or there's incompatibilities with later node&npm versions etc. If I have to recompile the project, then the solution is just to change the `flagsPath` parameter for the other package. I just dread having to recompile legacy node projects due to other reasons, so was hoping to avoid that by having the online link paths fixed by the original author. Alas, that's not going to happen.