I made the comment in the gitter room. Please disregard, it was a red herring.
same problem here too
Was able to fix that by adding a / 卯n front of assets. So, assets/logo.png should be /assets/logo.png.
yes. that solve the issue
OK, that sounds like a workaround for most cases, thank you @monojack .
Has anybody any idea how to overcome this issue if my app is not not served directly from the root of my domain (but from a subdirectory)?
By the way, this problem creeped into beta.15, too. Our project was building just fine but on a fresh checkout and npm install, since today it is broken ...
Same here, working on beta 15, now either have to use / in path or make the relative path point up to src by using appropriate number of ../.
I.e in my src/app/shared/layout/header/header.html, I have to use../../../../assets/someimg.jpg
It looks like the use of the html-loader was added via the AOT support PR. (commit: d29677815b039710041c107a29019a530703602f)
html-loader attempts to find the assets at build time and assumes the assets are relative to the referencing HTML file.
@hansl
The solution of @monojack doesn't work if you publish with a different <base></base> (with ng github-pages:deploy for example). This lead to broken assets
As @davinkevin mention, it do not work with custom base tag.
@TheLarkInn is there a way to use https://github.com/webpack/html-loader in which it works with relative paths AND with changed base-href?
Edit: some context https://github.com/webpack/html-loader/issues/85
We've reverted the change that lead to this scenario in #2537.
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
Was able to fix that by adding a
/卯n front ofassets. So,assets/logo.pngshould be/assets/logo.png.