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: files incorrectly determined as not being in an Angular project #1331

Merged
merged 1 commit into from
May 5, 2021

Conversation

atscott
Copy link
Collaborator

@atscott atscott commented May 5, 2021

I have observed that the performance enhancement introduced in #1272 does not
work in some situations. It appears that if I attempt to do operations in an
external template before the language service is initialized, the template will
be identified as not being inside an Angular project.

The result of this incorrect determination is that we will not service
requests for that file. This commit disables the check by always returning
true, effectively marking every TS and HTML file as being inside an
Angular project.

There may be some performance degradation in non-Angular projects as a
result due to additional file tokenization of TypeScript files. However,
we do still expect this tokenization to be very fast and there should be
no observable performance issues.

#1330

@atscott atscott added the target: patch This PR is targeted for the next patch release label May 5, 2021
@google-cla google-cla bot added the cla: yes label May 5, 2021
@atscott atscott force-pushed the disableIsInAngularProjectCheck branch from ae6bbe2 to cd9618a Compare May 5, 2021 18:57
I have observed that the performance enhancement introduced in angular#1272 does not
work in some situations. It appears that if I attempt to do operations in an
external template before the language service is initialized, the template will
be identified as not being inside an Angular project.

The result of this incorrect determination is that we will not service
requests for that file. This commit disables the check by always returning
`true`, effectively marking every TS and HTML file as being inside an
Angular project.

There may be some performance degradation in non-Angular projects as a
result due to additional file tokenization of TypeScript files. However,
we do still expect this tokenization to be very fast and there should be
no observable performance issues.

angular#1330
@atscott atscott force-pushed the disableIsInAngularProjectCheck branch from cd9618a to ecbf1fe Compare May 5, 2021 18:57
@atscott atscott added the action: merge Ready to merge label May 5, 2021
@atscott atscott merged commit 43bcbb7 into angular:master May 5, 2021
atscott added a commit that referenced this pull request May 5, 2021
…1331)

I have observed that the performance enhancement introduced in #1272 does not
work in some situations. It appears that if I attempt to do operations in an
external template before the language service is initialized, the template will
be identified as not being inside an Angular project.

The result of this incorrect determination is that we will not service
requests for that file. This commit disables the check by always returning
`true`, effectively marking every TS and HTML file as being inside an
Angular project.

There may be some performance degradation in non-Angular projects as a
result due to additional file tokenization of TypeScript files. However,
we do still expect this tokenization to be very fast and there should be
no observable performance issues.

#1330
(cherry picked from commit 43bcbb7)
@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 Jun 5, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
action: merge Ready to merge cla: yes target: patch This PR is targeted for the next patch release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants