Running multiple applications which proxy to each other breaks HMR
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 35/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Ferma
- Stack tecnologico
- angular, typescript, vite
- Ambito
- build-system, developer-experience, devtools
Direzione di ricerca
Inizia dal repository di riproduzione collegato e dal relativo README per riprodurre l'HMR tra applicazioni attraverso i proxy configurati. Poi segui la richiesta HMR del server di sviluppo Vite dell'Angular application builder, concentrandoti sul motivo per cui la risposta JavaScript aggiornata è vuota quando viene recuperata attraverso la porta di un'altra applicazione. Il lavoro è completato quando gli aggiornamenti a caldo vengono caricati correttamente tra le applicazioni tramite proxy e il comportamento di ricaricamento completo rimane intatto.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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
webpack-based dev-server HMR
Description
I work on a project which involves multiple separate Angular applications. They all live together in an Nx monorepository. It is the responsibility of one of these applications to handle user login. For ease of development, we have long configured each app and their proxies to handle forwarding to every other app, so that developers can start whichever apps are relevant to the work they are doing, log in using that app on its own port, and then navigate to other apps without needing to manually type a different port.
I hope this makes sense, I can try to explain more clearly if it doesn't. The important part is that we nearly always have more than one app running, and no matter which app's dev-server port you are on, they will always be able to forward requests intended for apps other than themselves. To achieve this each app has a unique base path which the proxy configuration uses to determine where to send requests.
We recently switched from the browser builder to the new application builder, and as a consequence the dev-server now uses Vite rather than Webpack. On the whole this has all been a great, apart from one thing: hot module reloading is broken cross-app.
I've created and linked a (somewhat minimal) reproduction repository below.
While investigating this myself, I noticed that when an app tries to hot update while on the "wrong" port, the part that seems to fail is fetching the new JavaScript file. The WebSocket connects just fine, receives the angular:component-update event just fine, and makes the request for the updated file just fine. The request even succeeds, actually, but the response is empty. Some screenshots for explanation:
It's worth noting that full-reload events work just fine, which is probably expected given the nature of what's failing about the hot reload.
That's as far as I've gotten. I'm not sure if there is some proxy configuration that I could do to fix this (I've tried some basic tweaks with no luck), or if this is a bug somewhere that needs to be fixed. But in the meantime, turning HMR off "fixes" things for us, though it isn't ideal of course.
Any help is appreciated, thank you!
Minimal Reproduction
https://github.com/tmercswims/ng-vite-mono-hmr
Includes reproduction steps in README.
Your Environment
Angular CLI: 19.2.12
Node: 22.15.0
Package Manager: npm 10.9.2
OS: darwin arm64
Angular: 19.2.11
... common, core, platform-browser, router
Package Version
------------------------------------------------------
@angular-devkit/architect 0.1902.12
@angular-devkit/build-angular 19.2.12
@angular-devkit/core 19.2.12
@angular-devkit/schematics 19.2.12
@angular/cli 19.2.12
@angular/compiler 19.2.11
@angular/compiler-cli 19.2.11
@schematics/angular 19.2.12
rxjs 7.8.2
zone.js 0.15.0
- Lingua principale
- TypeScript
- Stelle
- 27k
- Fork
- 11.8k
- Merge medio
- 16h 35m
- PR unite (30g)
- 176
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di angular/angular-cli
-
area: @angular/build gemini-triaged
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
angular/angular-cli#33955 ·
-
area: @angular/cli gemini-triaged
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
angular/angular-cli#33055 · 1 commento · 3 reazioni ·
-
unit-test: with --coverage, a setup file's hooks reach only the first spec file of each worker Apertaarea: @angular/build gemini-triaged
Difficoltà 4/5 3-5 giorni Idoneità per principianti 72/100
angular/angular-cli#34137 ·
-
angular/build:library area: @angular/build gemini-triaged
angular/angular-cli#34131 · 1 assegnatario ·
-
angular/build:library area: @angular/build gemini-triaged
angular/angular-cli#34130 · 1 assegnatario ·
Tutte le issue di angular/angular-cli
Issue simili
-
[Bug]: Discord Activity titles with emoji are rejected as over 80 characters when they are not Apertaclawsweeper:linked-pr-open clawsweeper:no-new-fix-pr clawsweeper:source-repro impact:message-loss issue-rating: 🦞 diamond lobster maturity:stable P2
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
Eynzof/Hermes-CN-Desktop#616 ·
-
ZCode 3.14.3 に対応する Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
supermomonga/zcode-acp#24 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
growthbook/growthbook#7100 ·
-
triage
Difficoltà 1/5 1-3 ore Idoneità per principianti 88/100