Skip to content
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

fix(compiler-cli): do not persist component analysis if template/styles are missing #49184

Closed

Conversation

devversion
Copy link
Member

@devversion devversion commented Feb 23, 2023

Consider the following scenario:

  1. A TS file with a component and templateUrl exists
  2. The template file does not exist.
  3. First build: ngtsc will properly report the error, via a FatalDiagnosticError
  4. The template file is now created
  5. Second build: ngtsc still reports the same errror.

Ngtsc persists the analysis data of the component and never invalidates it when the template/style
file becomes available later.

This breaks incremental builds and potentially common workflows where resource files are added
later after the TS file is created. This did not surface as an issue in the Angular CLI yet because Webpack
requires users to re-start the process when a new file is added. With ESBuild this will change and this
also breaks incremental builds with Bazel/Blaze workers.

To fix this, we have a few options:

  • Invalidate the analysis when e.g. the template file is missing. Never caching it means that it will be
    re-analyzed on every build iteration.
  • Add the resource dependency to ngtsc's incremental file graph. ngtsc will then know via host.getModifiedResources when the file becomes available- and fresh analysis of component would occur.

The first approach is straightforward to implement and was chosen here. The second approach would
allow ngtsc to re-use more of the analysis when we know that e.g. the template file still not there, but it
ncreases complexity unnecessarily because there is no single obvious resource path for e.g. a templateUrl.
The URL is attempted to be resolved using multiple strategies, such as TS program root dirs, or there is support
for a custom resolution through host.resourceNameToFileName.

It would be possible to determine some candidate paths and add them to the dependency tracker, but it
seems incomplete given possible external resolvers like resourceNameToFileName and also would likely
not have a sufficient-enough impact given that a broken component decorator is not expected to remain
for too long between N incremental build iterations.

…es are missing

Consider the following scenario:

1. A TS file with a component and templateUrl exists
2. The template file does not exist.
3. First build: ngtsc will properly report the error, via a FatalDiagnosticError
4. The template file is now created
5. Second build: ngtsc still reports the same errror.

ngtsc persists the analysis data of the component and never invalidates
it when the template/style file becomes available later.

This breaks incremental builds and potentially common workflows
where resource files are added later after the TS file is created. This
did surface as an issue in the Angular CLI yet because Webpack requires
users to re-start the process when a new file is added. With ESBuild
this will change and this also breaks incremental builds with
Bazel/Blaze workers.

To fix this, we have a few options:

* Invalidate the analysis when e.g. the template file is missing. Never
  caching it means that it will be re-analyzed on every build iteration.
* Add the resource dependency to ngtsc's incremental file graph. ngtsc
  will then know via `host.getModifiedResources` when the file becomes
  available- and fresh analysis of component would occur.

The first approach is straightforward to implement and was chosen here.
The second approach would allow ngtsc to re-use more of the analysis
when we know that e.g. the template file still not there, but it
increases complexity unnecessarily because there is no **single**
obvious resource path for e.g. a `templateUrl`. The URL is attempted
to be resolved using multiple strategies, such as TS program root dirs,
or there is support for a custom resolution through
`host.resourceNameToFileName`.

It would be possible to determine some candidate paths and add them to
the dependency tracker, but it seems incomplete given possible external
resolvers like `resourceNameToFileName` and also would likely not have
a sufficient-enough impact given that a broken component decorator is
not expected to remain for too long between N incremental build
iterations.
@devversion devversion force-pushed the fix-incremental-template-resource branch from 01774df to 41f1a0a Compare February 23, 2023 17:49
@devversion devversion added action: review The PR is still awaiting reviews from at least one requested reviewer target: patch This PR is targeted for the next patch release area: compiler Issues related to `ngc`, Angular's template compiler labels Feb 23, 2023
@ngbot ngbot bot added this to the Backlog milestone Feb 23, 2023
@devversion devversion marked this pull request as ready for review February 23, 2023 18:22
@devversion devversion added action: merge The PR is ready for merge by the caretaker and removed action: review The PR is still awaiting reviews from at least one requested reviewer labels Feb 23, 2023
@AndrewKushnir
Copy link
Contributor

@devversion it looks like presubmit info is missing, could you please update the status or leave a comment about the presubmit state, so that we can proceed with the merge?

@devversion
Copy link
Member Author

@AndrewKushnir started presubmit now. The caretaker queue filter should only show it when all statuses are green, but feel free to remove the label if you prefer that.

@AndrewKushnir AndrewKushnir added action: presubmit The PR is in need of a google3 presubmit and removed action: merge The PR is ready for merge by the caretaker labels Feb 23, 2023
@devversion devversion added action: merge The PR is ready for merge by the caretaker and removed action: presubmit The PR is in need of a google3 presubmit labels Feb 23, 2023
@AndrewKushnir
Copy link
Contributor

This PR was merged into the repository by commit b6c6dfd.

AndrewKushnir pushed a commit that referenced this pull request Feb 24, 2023
…es are missing (#49184)

Consider the following scenario:

1. A TS file with a component and templateUrl exists
2. The template file does not exist.
3. First build: ngtsc will properly report the error, via a FatalDiagnosticError
4. The template file is now created
5. Second build: ngtsc still reports the same errror.

ngtsc persists the analysis data of the component and never invalidates
it when the template/style file becomes available later.

This breaks incremental builds and potentially common workflows
where resource files are added later after the TS file is created. This
did surface as an issue in the Angular CLI yet because Webpack requires
users to re-start the process when a new file is added. With ESBuild
this will change and this also breaks incremental builds with
Bazel/Blaze workers.

To fix this, we have a few options:

* Invalidate the analysis when e.g. the template file is missing. Never
  caching it means that it will be re-analyzed on every build iteration.
* Add the resource dependency to ngtsc's incremental file graph. ngtsc
  will then know via `host.getModifiedResources` when the file becomes
  available- and fresh analysis of component would occur.

The first approach is straightforward to implement and was chosen here.
The second approach would allow ngtsc to re-use more of the analysis
when we know that e.g. the template file still not there, but it
increases complexity unnecessarily because there is no **single**
obvious resource path for e.g. a `templateUrl`. The URL is attempted
to be resolved using multiple strategies, such as TS program root dirs,
or there is support for a custom resolution through
`host.resourceNameToFileName`.

It would be possible to determine some candidate paths and add them to
the dependency tracker, but it seems incomplete given possible external
resolvers like `resourceNameToFileName` and also would likely not have
a sufficient-enough impact given that a broken component decorator is
not expected to remain for too long between N incremental build
iterations.

PR Close #49184
@angular-automatic-lock-bot
Copy link

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.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Mar 27, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
action: merge The PR is ready for merge by the caretaker area: compiler Issues related to `ngc`, Angular's template compiler target: patch This PR is targeted for the next patch release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants