Angular CLI: 6.0.0-rc.4
Angular*: 6.0.0-rc.5
"allowOutsideOutDir":true still not works here (6rc4)?
in my architect.build.options i have:
"assets": [
{
"glob": "favicon.ico",
"input": "src",
"output": "../",
"allowOutsideOutDir":true
},
{
"glob": "**/*",
"input": "src/assets",
"output": "../assets",
"allowOutsideOutDir":true
}
]
Data path ".assets[0]" should NOT have additional properties(allowOutsideOutDir).
this issue https://github.com/angular/angular-cli/issues/10284 seems improve message error but not fix allowOutsideOutDir ?
We did remove the allowOutsideOutDir option, yes. It didn't make as much sense in the new multi-project setups, nor did it make sense with how we now handle paths for assets.
Can you tell me about your use case please? You seem to be outputing all assets outside the output dir for the project.
Yes correct i have multiple language. So /assets folder is same for all language and without output my assets outside each language make them exist everywhere
/fr
/de
/en
/it
Have their /assets which are exactly same i just want have it once and this option allowed it.
This option was discussed and was added by @hansl itselft as option to cover usecase (see closed issues) i don鈥檛 see how can I here have this behavior without it. Thanks
What's the problem in having assets inside each folder though? Does it break something?
If they are different applications (their source code is different) then they should have their own assets. I agree it is a bit wasteful to have the exact same files in each folders but they are for all intents and purposes different applications.
Problems:
/assets folder were ../assets/images... instead ./assets /images... due to this option activated in v1.7.x but ok this can quickly be fixed with search/replace in my projectI understand what you said but today I have 6mo /assets folder and it is in all my /{language} folder ! Big dammage, not you think so ?
yes we can! relativly say it's not related to cli but Angular itself to not support multiple locale in one bundle ! https://github.com/angular/angular/issues/16477
But can't we let this option here until angular improve i18n? IMHO we should :)
@filipesilva My use case is a little bit different. We always serve content from the server to the client from the root folder (dist). Say I have 2 applications that share assets. So in dist I have application1 and application2. In these applications I'm linking to some asset box.jpg so the link would be assets/box.jpg. The server would try to fetch this asset as assets/box.jpg not application1/assets/box.jpg or application2/assets/box.jpg since it will always fetch from the root. The server is going to return a 404. Previously I built the assets outside the application folder which would solve my issue.
And previously I had different assets configuration for serve and build. In serve I don't need the assets to be outside of dir but in build yes. I achieved this by having multiple apps for the same app application1 and application1-prod
Marking this as required for the release, but only a decision needs to be made.
I have a multi-locale application as well, and my use case is this:
dist/
app1/
en/index.html
fr/index.html
sitemap.xml
app2/
en/index.html
de/index.html
sitemap.xml
sitemap.xml in that example needs to be 'outside' the destination path which is dist/app/locale.
@filipesilva @hansl am I doing things wrong with how CLI is supposed to work now?
Are there any updates?
My use case FWIW: I maintain 4 (and more to come) Angular apps inside a large project with JSON assets that contain localization strings. These JSON assets are exported from a C# API server, and are consumed by my apps along with other legacy applications that need to read the same strings. It doesn't make sense then to store those assets inside my CLI project. Without the convenience of allowOutsideOutDir I'll have to script it elsewhere. Not terrible, it'll be an adventure.
Closing this option was removed on purpose and writing outside might potentially causes problems when deploying such as when using ng deploy.
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._
Most helpful comment
Marking this as required for the release, but only a decision needs to be made.