The command ng serve is not responding to changes to ng module #34813
Comments
|
I think that's actually related to |
|
@filipesilva Sorry, I'm still a little new here. Could you clarify what you mean by "the latest RC"? Based on the output from running |
|
Yes rc.5 is the latest RC, but https://github.com/wagnermaciel/Pokedex/blob/master/package.json was using rc.2 so I just wanted to make sure. Will look into it, thanks! |
|
Ah, got it. I'll take another look when I get the chance. Thank you! |
|
I tried this out again and it seems to be fixed - somewhere between @filipesilva I spoke with @dgp1130 and we concluded that although |
|
Seems like I was able to reproduce this. I believe this issue is mainly to do with how I've created as simple an angular app to demo the bug as I could. As a recap - The bug happens when a component is undeclared but used through the Here is my current environment
cc: @dgp1130 |
|
I think the answer to the |
|
@wagnermaciel, wasn't there a way to run |
|
Yes, the issue here is not that the build fails or succeeds. The issue is that an iterative rebuild can look like everything is working just fine but killing and restarting the server will show that the app is actually crashing, or vice-versa. |
alxhub
added
area: compiler
|
Confirmed as reported in rc.9. There are actually two bugs here!
|
|
I've reproduced this in the compiler's incremental build tests now. The general flow of the bug is:
Here's where things go off the rails. If the component had been moved from one module to another, it would have a dependency on its new module's file, which would have changed (to add the component). This would trigger an emit of the component. But because the component now has no associated module, it now has no outgoing dependency edges to anything that's changed. Therefore, the incremental build engine decides that the component isn't stale after all, and does not require a re-emit. What's missing from this picture is the understanding that not depending on a module is, in fact, a change. Somehow, we need to carry forward the information that the component file still depends on the module file in the new program, because the removal of the component from the module is still a change which affects the component. I'll have to think about how to express this cleanly. |
This commit fixes a bug in the incremental rebuild engine of ngtsc, where if a component was removed from its NgModule, it would not be properly re-emitted. The bug stemmed from the fact that whether to emit a file was a decision based purely on the updated dependency graph, which captures the dependency structure of the rebuild program. This graph has no edge from the component to its former module (as it was removed, of course), so the compiler erroneously decides not to emit the component. The bug here is that the compiler does know, from the previous dependency graph, that the component file has logically changed, since its previous dependency (the module file) has changed. This information was not carried forward into the set of files which need to be emitted, because it was assumed that the updated dependency graph was a more accurate source of that information. With this commit, the set of files which need emit is pre-populated with the set of logically changed files, to cover edge cases like this. Fixes angular#34813
This commit fixes a bug in the incremental rebuild engine of ngtsc, where if a component was removed from its NgModule, it would not be properly re-emitted. The bug stemmed from the fact that whether to emit a file was a decision based purely on the updated dependency graph, which captures the dependency structure of the rebuild program. This graph has no edge from the component to its former module (as it was removed, of course), so the compiler erroneously decides not to emit the component. The bug here is that the compiler does know, from the previous dependency graph, that the component file has logically changed, since its previous dependency (the module file) has changed. This information was not carried forward into the set of files which need to be emitted, because it was assumed that the updated dependency graph was a more accurate source of that information. With this commit, the set of files which need emit is pre-populated with the set of logically changed files, to cover edge cases like this. Fixes angular#34813
This commit fixes a bug in the incremental rebuild engine of ngtsc, where if a component was removed from its NgModule, it would not be properly re-emitted. The bug stemmed from the fact that whether to emit a file was a decision based purely on the updated dependency graph, which captures the dependency structure of the rebuild program. This graph has no edge from the component to its former module (as it was removed, of course), so the compiler erroneously decides not to emit the component. The bug here is that the compiler does know, from the previous dependency graph, that the component file has logically changed, since its previous dependency (the module file) has changed. This information was not carried forward into the set of files which need to be emitted, because it was assumed that the updated dependency graph was a more accurate source of that information. With this commit, the set of files which need emit is pre-populated with the set of logically changed files, to cover edge cases like this. Fixes angular#34813
…34912) This commit fixes a bug in the incremental rebuild engine of ngtsc, where if a component was removed from its NgModule, it would not be properly re-emitted. The bug stemmed from the fact that whether to emit a file was a decision based purely on the updated dependency graph, which captures the dependency structure of the rebuild program. This graph has no edge from the component to its former module (as it was removed, of course), so the compiler erroneously decides not to emit the component. The bug here is that the compiler does know, from the previous dependency graph, that the component file has logically changed, since its previous dependency (the module file) has changed. This information was not carried forward into the set of files which need to be emitted, because it was assumed that the updated dependency graph was a more accurate source of that information. With this commit, the set of files which need emit is pre-populated with the set of logically changed files, to cover edge cases like this. Fixes #34813 PR Close #34912
…ngular#34912) This commit fixes a bug in the incremental rebuild engine of ngtsc, where if a component was removed from its NgModule, it would not be properly re-emitted. The bug stemmed from the fact that whether to emit a file was a decision based purely on the updated dependency graph, which captures the dependency structure of the rebuild program. This graph has no edge from the component to its former module (as it was removed, of course), so the compiler erroneously decides not to emit the component. The bug here is that the compiler does know, from the previous dependency graph, that the component file has logically changed, since its previous dependency (the module file) has changed. This information was not carried forward into the set of files which need to be emitted, because it was assumed that the updated dependency graph was a more accurate source of that information. With this commit, the set of files which need emit is pre-populated with the set of logically changed files, to cover edge cases like this. Fixes angular#34813 PR Close angular#34912
|
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. |
🐞 Bug report
Command
Description
ng serveeither is not responding to changes made to thedeclarationsproperty of anNgModule.🔬 Minimal Reproduction
ng new pokemon --routing=false --style=cssng generate component pokedexpokedexto be used by the root componentng servepokedexfrom thedeclarationsfield of theNgModuleinapp.module.tsExpected
The app crashes
Actual
The app continues working
Additional Information
Restarting
ng servefixes the issue.This also works vice-versa, so if the application is crashing due to
pokedexnot being in thedeclarationsofapp.module.ts, adding it without restartingng servewill still be crashing.🌍 Your Environment
Demo
I've created a demo project here.
To reproduce this issue
git clone https://github.com/wagnermaciel/Pokedex.gitnpm installng servePokedexComponentfrom thedeclarationsof theNgModuleinsrc/app.app.module.tsThe text was updated successfully, but these errors were encountered: