Support renaming of asset file

[JaapMosselman]

Feature request

It would be nice have an option to rename an asset in certain situations, e.g. when having conflicts in third party stuff.
Add property "filename" with the new file name.
Will only be used when the glob resolves to exactly one file.

"assets": [
  { "glob": "**/*", "input": "./assets/", "output": "./assets/" },
  { "glob": "favicon.ico", "input": "./", "output": "./", "filename": "newname.ico" },
]

[gagle]

Any news with Angular 6?

[bdbrown4]

Any updates here? https://github.com/webpack-contrib/copy-webpack-plugin already provides this solution.

[IonelLupu]

One and a half years later, we still need this.
Example: I have a list o transactions that used different credit cards (visa, master card, paypal etc.) and I am using a library that provides SVGs for these cards. The problem is that the library named the no found credit card as default.svg but my backend (which I can't change) returns this type of card as not_found and not default.

I need this angular feature to renamed default.svg to not_found.svg

[FloNeu]

@alan-agius4 Refering to Closed Ticket #16779. You mentioned file-replacement section in angular.json was only intended to work with files that are added to a bundle - and it working for regular-files was kind of an error. But why was this behaviour changed ( without so much as a mention or a deprication-warning ) as I am not aware this caused any problems... For me this caused major headaches and suddenly breaking my pwa-install features ( because I have manifest-files for different environments ) after updating from ng9 to ng10. Now I had to refector a whole punch of apps, because there is no replacement allowing the previous behaviour with current angular version. Can't this be reverted, deprecated and transparently reintroduced when this is implemented?

[alan-agius4]

Hi @FloNeu, the behaviour was changed in version Angular CLI version 9 during one of the RC's. In version 9 we introduced another layer in the build process to support downlevelling, parallel copying of assets and the new Ivy i18n. In this layer fileReplacements doesn't exists because at this point the bundles have been created, and source files which needed to be replaced have been.

While I understand that this might be an inconvenience for some. I don't think it's feasible to implement a feature to remove it in 2 major versions.

[FloNeu]

That's not what i meant... I meant it's not alright to change a feature of the client and say this is how it is supposed to work - while publicly i couldn't find any note that the fileReplacement feature is indented to only work for bundle-files - without any kind of warning or deprecation - I would say that's a breaking change. When you read the docs it only states that you can replace files per build targets - again no mention of bundles. Imho the change from 9 RC should be reverted. That I didn't even noticed that my builds already broke with version 9 - not 10 should show that at least a warning should be given when fileReplacement is used on none-bundle files. Breaking builds is not an inconvenience - this kind of comment sadly reminds me of the terrible updates on below <6 versions. I already stopped using this framework once - because of all the problems with undocumented breaking changes on every other version upgrade... and I hoped this times would be over Am Fr., 28. Aug. 2020 um 13:58 Uhr schrieb Alan Agius < notifications@github.com>:

…

Hi @FloNeu <https://github.com/FloNeu>, the behaviour was changed in version Angular CLI version 9 during one of the RC's. In version 9 we introduced another layer in the build process to support downlevelling, parallel copying of assets and the new Ivy i18n. In this layer fileReplacements doesn't exists because at this point the bundles have been created, and source files which needed to be replaced have been. While I understand that this might be an inconvenience for some. I don't think it's feasible to implement a feature to remove it in 2 major versions. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#8808 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKPZ6D23HHRRC3UY44FFHDSC6LUTANCNFSM4EHNLYQA> .