Repository navigation
application builder not loading css from localhost correctly with ng serve when using remote dev with HMR #29248
Description
Command
serve
Is this a regression?
- Yes, this behavior used to work in the previous version
The previous version in which this bug was not present was
18.2.11
Description
When using the application builder to serve on localhost, but with the main website loaded from a remote dev server, stylesheets are not loading properly for us as of Angular CLI 19.
For our development environment, we are loading our main website (including index.html) from a remote dev server (say, dev.example.com), but running ng serve from localhost. To do this, we have been serving a copy of index.html when appropriate (not all pages of the application use Angular) from the remote dev server, and rewriting all the src attributes in index.html to point //localhost:4200/main.js, etc so that vite, the js, and the main css load correctly.
In Angular 18, the result of this is that all the js chunk files are requested from localhost, and all of the other requests go to our dev server--this is the intended behavior. In particular, the js chunks for components had all of the styles inlined in the js file.
In Angular 19, we are seeing new requests, for css files, requests we never saw in Angular 18, presumably because these stylesheets are no longer inlined in the js. Unfortunately, these requests for css files are going to our remote dev server, but are, of course, being served by localhost, so we are getting 404s for all of these.
I'm calling this a regression, because styles worked properly in dev for Angular 18 but not Angular 19, but I recognize that our use case is unusual. I'd like to find some solution that allows us to run a dev environment for Angular 19, probably by getting the CSS files to load from the localhost, but if there is some other solution (perhaps returning to inlining stylesheets in the js files?), I'm open to that as well.
(I initially thought this was related to the deployUrl feature (see #26411) which we use in production to serve js and stylesheets from a CDN, and am still a little concerned about whether this will be a problem for us in production.)
EDIT: As noted below in the comments, this is happening because HMR has been turned on by default in Angular 19. I suspect that the sort of configuration I'm using has never worked with HMR.
Minimal Reproduction
Serve index.html (with the srcs rewritten to load from localhost) from a server different from localhost.
run ng serve on localhost.
Try to load the site on from the remove server.
Exception or Error
Your Environment
Angular CLI: 19.0.6
Node: 18.20.5
Package Manager: yarn 1.22.22
OS: darwin arm64
Angular: 19.0.5
... animations, common, compiler, compiler-cli, core, forms
... language-service, localize, platform-browser
... platform-browser-dynamic, router
Package Version
---------------------------------------------------------
@angular-devkit/architect 0.1900.6
@angular-devkit/build-angular 19.0.6
@angular-devkit/core 19.0.6
@angular-devkit/schematics 19.0.6
@angular/cdk 19.0.4
@angular/cli 19.0.6
@schematics/angular 19.0.6
rxjs 7.8.1
typescript 5.5.4
zone.js 0.15.0
Anything else relevant?
No response
Activity
JoostK commentedon Jan 4, 2025
Disable HMR to have CSS styles be inserted as style elements instead of links.
karptonite commentedon Jan 5, 2025
@JoostK I didn't think I was using HMR. Was that something that got turned on by default for Angular 19, do you know?
Edit: I see now that it is turned on by default. I can turn it off, but it would be great if HMR worked in this case also. Not sure if that is something that is in the cards, though.
[-]`application` builder not loading css from localhost correctly with `ng serve` when using remote dev[/-][+]`application` builder not loading css from localhost correctly with `ng serve` when using remote dev with HMR[/+]karptonite commentedon Jan 6, 2025
It is questionable now whether this is a regression; I've never used HMR before, I think, and the only reason this broke now is that HMR was turned on by default now. My guess is that my use case never worked with HMR before. Nonetheless, it would be ideal if it did work.
Tabbiefox commentedon Jan 8, 2025
Also experiencing the same issue after migrating from Angular 17 to Angular 19. Both configurations had HMR (Hot Module Replacement) enabled. In Angular 17, the component styles were working correctly, but after the upgrade to Angular 19, the styles stopped working as expected.
The problem is that the component style links are missing any host/port information, despite it being configured in the angular.json. Additionally, the servePath setting, which I was hoping to use as a workaround, is also ignored. Regardless of how I configure my serve environment, the generated stylesheet links are always pointing to the root of the host environment, instead of the correct path as defined in the configuration.
That being said, turning off the HMR did solve the issue.
ZhetoN commentedon Jan 11, 2025
same issue, no port added to css links. disabling hrm fixes issue
alan-agius4 commentedon Jan 17, 2025
The problem appears to be that
/@ng/componentsis set to an absolute url.https://github.com/angular/angular/blob/4e6017a9f5cda389c5fbf4f2c1519ce1bba23e11/packages/compiler/src/render3/r3_hmr_compiler.ts#L57
refactor(@angular/build): handle relative `@ng/components`
refactor(@angular/build): handle relative `@ng/components`
refactor(@angular/build): handle relative `@ng/components`
refactor(@angular/build): handle relative `@ng/components`
fix(@angular/build): handle relative `@ng/components`
fix(compiler): update `@ng/component` URL to be relative
fix(compiler): update `@ng/component` URL to be relative (#59620)
fix(compiler): update `@ng/component` URL to be relative (angular#59620)
fix(@angular/build): handle relative `@ng/components`
fix(@angular/build): handle relative `@ng/components`
fix(compiler): update `@ng/component` URL to be relative (angular#59620)
angular-automatic-lock-bot commentedon Feb 20, 2025
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.