-
Notifications
You must be signed in to change notification settings - Fork 12k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Module path prefix is not used to resolve styleUrl or templateUrl with AoT #5056
Comments
Sounds like a bug to me. Thanks for reporting it! |
@sumitarora can you have a look? |
@PierreDuc Is there a repo that I can check the issue. I tried to replicate and it seems to be failing in bot
|
@sumitarora I've created a repo https://github.com/PierreDuc/angular-cli-test.git If you run How it is now:
The parsing is done, at least for Preferably (at least for me) will be that a Less preferable, but still workable would be that in |
This is actually a "bug" in JIT. What JIT does is replace #3842 should have aligned both together, but instead relies on webpack to resolve it in JIT. The solution here is to remove the webpack resolution from the loader. We're aware this will cause pain for people and are talking internally to make sure the plan is clear. |
That's what I was afraid of. I suspect this 'feature' of |
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
OS?
Versions.
Repro steps.
Due to reasons we have our style sheets in a separate root folder. A couple versions ago we were able to load the styling using:
Then something changed a couple versions ago and module paths were resolved as relative paths, so
./
was appended to the url. This is done in theloader-utils
package. I've read there that I could append a~
to the url, to convert it to a module request. (~@style_folder/bla/bla
) This worked splendidly (with the minor downside that I could no longer navigate to it using my IDE).We are in the process of making our application AoT compatible, and to our big surprise, the
~
trick doesn't work there, because AoT thinks it's a relative path no matter what.We would prefer it to not have all relative paths inside our
styleUrls
(../../../ horror). Better would be that both JIT and AoT look at the paths defined intsconfig.json
(like it was before I believe) and look there for a definition, and only after that assume it's a relative path if there is no match.The text was updated successfully, but these errors were encountered: