Asset copy with wildcard in the input path

[Ketec]

🚀 Feature request

Command (mark with an x)

- [ ] new
- [ x] build
- [ x] serve
- [x ] test
- [ x] e2e
- [ ] generate
- [ ] add
- [ ] update
- [ ] lint
- [ ] xi18n
- [ ] run
- [ ] config
- [ ] help
- [ ] version
- [ ] doc

Description

Currently assets array allows glob with input path, however input path itself does not support wildcards.
Like ./node_modules/@myscope/**/assets/i18n/*
Where ** is any number of unknown libraries (like shared, services, featureabc).

With glob it would also create every folder between @Myscope to assets/i18n, instead of copying just the contents of i18n.

Describe the solution you'd like

The input path allows wildcards to set the root or a flag to only copy contents of the glob result path.

Describe alternatives you've considered

Node scripts that requires extra steps and wouldn't know if project output is different from dist and it does not work with serve.

[angular-robot]

Just a heads up that we kicked off a community voting process for your feature request. There are 20 days until the voting process ends.

Find more details about Angular's feature request process in our documentation.

[angular-robot]

Thank you for submitting your feature request! Looks like during the polling process it didn't collect a sufficient number of votes to move to the next stage.

We want to keep Angular rich and ergonomic and at the same time be mindful about its scope and learning journey. If you think your request could live outside Angular's scope, we'd encourage you to collaborate with the community on publishing it as an open source package.

You can find more details about the feature request process in our documentation.

[aaronscribner]

Given the growing popularity of micro-frontends, can we revisit this topic?

It would be very helpful to have all of the assets from all of the individual MFEs copied to the shell/assets directory, from which they must load.

[alan-agius4]

Thank you for taking the time to submit this feature request.

At this time, we are not planning to implement this feature, as it did not gather sufficient community interest and we want to be mindful of expanding the CLI configuration surface area when existing workarounds are available.

We will be closing this issue as not planned for now, though we are happy to reconsider it in the future if community interest changes.