HMR will drop styles applied to a component if an HTML element in a component is changed · Issue #59558 · angular/angular · GitHub
Skip to content

HMR will drop styles applied to a component if an HTML element in a component is changed #59558

Closed

Description

@msmallest

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

19.0.7

Description

When a template save occurs that changed an HTML element's inner content, such as adding text inside of a <p> tag for example, the styles of that component stop applying. This can temporarily be solved by adding something like a character, for example !, outside of an HTML element.

Though template HMR is new as the default in 19.1, I consider this a regression since the same ng serve command now produces different results.

Minimal Reproduction

Process

(in the 19.1's)

  1. Add or remove any character from text inside of an HTML element. For example, add an ! inside any of the <p> tags.
  2. Observe that all styles no longer apply to that component's template
  3. Observe that if you add a character outside of an HTML element, such as below the comment and above the <p> aka on line 14, that the styles once again apply after an HMR refresh.
  4. Repeat 1-3 as needed.

This is true with changes in either the main.ts inline template or the external template component which is placed inside of main.ts's template. But one breaking or fixing following the steps doesn't seem to fix the other template's issues.

Commands run (including args):

ng serve

Packages added

None beyond Stackblitz starter which was bumped to 19.1.0 for all packages, or a CLI generated app also being bumped from 19.0.6 to 19.1.0 for all packages. Both done manually since I couldn't get the CLI to bump with an ng update.

Reproductions: 2 Stackblitzes and 1 repo

Two Stackblitzes with the default stackblitz configuration, aka serves with "builder": "@angular/build:dev-server",

19.0.6 with only style HMR (by default)

Angular 19.1 with style HMR and template HMR (by default)

Repo that is essentially the 19.1 Stackblitz, but using "builder": "@angular-devkit/build-angular:dev-server", as the CLI auto generates to use. Same type of issue occurs.

19.1-hmr-issue

Related code changes

To get parity I condensed the CLI app to be structured closer to the Stackblitz starters, meaning taking extra configuration out of main.ts and placing the root file and config in there. The builders of the CLI app remain the same since that is what CLI generated apps use.

As for overall changes from general starting states of apps, this consists of one root component with inline template and inline style properties, and then one component with an external template but internal style property.

Potentially related but ruled out of this reproduction: I wonder if another scenario where there is a component with inline template but exterior style impacts anything, but so much was going on already.

Exception or Error


Your Environment

## Stackblitz

Angular CLI: 19.1.0
Node: 18.20.3
Package Manager: npm 10.2.3
OS: linux x64

Angular: 19.1.0
... animations, build, cli, common, compiler, compiler-cli, core
... forms, platform-browser, router

Package                      Version
------------------------------------------------------
@angular-devkit/architect    0.1901.0
@angular-devkit/core         19.1.0
@angular-devkit/schematics   19.1.0
@schematics/angular          19.1.0
rxjs                         7.8.1
typescript                   5.7.3
zone.js                      0.15.0

## Macbook that ran the CLI generated app

Angular CLI: 19.1.0
Node: 20.11.1
Package Manager: npm 10.2.4
OS: darwin arm64

Angular: 19.1.0
... animations, cli, common, compiler, compiler-cli, core, forms
... platform-browser, platform-browser-dynamic, router

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1901.0
@angular-devkit/build-angular   19.1.0
@angular-devkit/core            19.1.0
@angular-devkit/schematics      19.1.0
@schematics/angular             19.1.0
rxjs                            7.8.1
typescript                      5.6.3
zone.js                         0.15.0

Anything else relevant?

Same issue applies on my Windows 11 in either Stackblitzes or running from a WSL2 Ubuntu local dev server.

All of this is in Chrome, and I just checked Firefox on the Mac and the same occured.

Activity

  1. alan-agius4 commented on Jan 16, 2025

    @alan-agius4
    Contributor

    Transferring to the FW as this is a runtime issues.

  2. self-assigned this
    on Jan 16, 2025
  3. added a commit that references this issue on Jan 16, 2025
    bc33950
  4. added a commit that references this issue on Jan 16, 2025
    eb0b185
  5. added a commit that references this issue on Jan 16, 2025
    2fe54a1
  6. michael-small commented on Jan 16, 2025

    @michael-small
    Contributor

    Wow, that was fast. Thank you all.

  7. JMS-1 commented on Jan 17, 2025

    @JMS-1

    I'm not fully sure if this is the same issue: wie are observing that changes in SCSS will not proper be reloaded if the containing component has been lazy loaded. This is still in 19.1.1 and very annoying since right now a full serve restart is needed to see the changes.

  8. alan-agius4 commented on Jan 17, 2025

    @alan-agius4
    Contributor

    @JMS-1, unfortunately, it's difficult to determine the root cause without a minimal reproduction. As a workaround, you can disabling HMR by using --no-hmr.

  9. JMS-1 commented on Jan 17, 2025

    @JMS-1

    Actually as I experience it right now HMR is seriously broken in 19.1.0 and 19.1.1 so instead of providing a repro of our specific case I'll wait for 19.1.2 or so before I try to report a regular bug. Currently I can't imagine anyone relying on HMR before 19.1.0 will have any fun working with angular right now.

  10. JMS-1 commented on Jan 21, 2025

    @JMS-1

    FYI: with 19.1.3 at least SASS changes will become visible after save. Although it looks as if the app does a full reload. Seems that waiting a bit for more fixes can help...

  11. added a commit that references this issue on Feb 7, 2025
    b520924
  12. angular-automatic-lock-bot commented on Feb 21, 2025

    @angular-automatic-lock-bot

    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.

  13. locked and limited conversation to collaborators on Feb 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions