-
Notifications
You must be signed in to change notification settings - Fork 122
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
Support project references / solution-style configs (common in Nx projects) #876
Comments
I have the same problem when using Nx workspace layout. I get no intellisense in any lib. |
Please show us two logs:
|
|
That's what I am using also. It did work, as recently as last week. It seems vscode has issues with nx workspaces using a tsconfig.base.json and having each lib's tsconfig.json point to it. |
Does this happen if you use the stable version of vscode? |
I seem to be having the same (or similar) issue. No intellisense and the editor thinks that components from my library don't exist. However, they do work. If I disable or remove the Language Service extension, the editor warning goes away - but obviously still no intellisense. |
Does not work in non-insiders VSCode, but I get different output:
|
Each nxjs /lib directory has its own tsconfig.json like this
and the tsconfig.base.json they all point to is this:
|
It would seem this is an issue with Angular 10 using tsconfig.base.json file. I am finding many issues on VSCode and Webstorm related to this. |
I think I found a workaround of sorts...
to something like this:
tsconfig.lib.json and tsconfig.spec.json for the lib should extend the tsconfig.json you modified - so basically no changes there Here's my tsconfig.lib.json for reference:
Hope this helps! |
I'm having this same issue with an NX 12 workspace and Angular 11.2+. The Language service does not pick up configured paths in the Is there something that the language service can be given a glob or file pointer to include for suggestions? |
Hey a little hint for everyone who uses the This starts to be problematic for the Angular Language Service because as far as I understand the source code of it it's core functions base on Solution seems to be very simple: your Example:
|
Okay so I was troubleshooting pipes, directives and components showing up as undeclared after I opened up certain files. I was doing this because I use NativeScript and I prefer not to have a bunch of DOM types that don't exist at runtime. So it's not much of a workaround as I can't configure the types how I would like, but I was able to get the language server to not give me errors anymore by not configuring the If this really is the issue (or at least one of them) perhaps it could be fixed soon? Let me know if you'd like a recreation. |
I just created a new pre-release version of the language service that adds the option to disable ngcc manually. That step has been problematic for many developers. You can download the release here: https://github.com/angular/vscode-ng-language-service/releases/tag/v14.0.0-next.0. Note that disabling ngcc will mean that you it will likely need to be run outside of the extension, though this is done during the build step anyways so if you're running a dev server while you're coding, you likely won't have to worry about this. For those experiencing this issue, can you check if disabling ngcc in the extension options resolves the problem? |
Closing as fixed by fbc9e2b. See #876 (comment) |
Re-opening as I think there can and should be further work done here. |
Additional reproductions in #1616 (comment) and #1581 (comment) |
When opening a file, TypeScript looks for the project which references the file directly (see https://sourcegraph.com/github.com/microsoft/TypeScript@4d2fb5407c4e9999dd108972290fc57d3dd56e71/-/blob/src/server/editorServices.ts?L3353-3390) for the purposes of providing diagnostics. I haven't been able to confirm how this works with other commands/actions (go to definition/quick info/ etc). I'm also not sure how exactly this would work with angular template files since |
I also suspect much of the recent instability has been due to the regression of #1438 (reopened as #1623). #1447 ensured that language services get enabled in the order they're defined in the tsconfig references. In nx workspaces, this is generally the Because projects are no longer kept open (again, the regression of #1438) the strategy in #1447 is breaking down. |
…open VSCode/TSServer implements an optimization to close projects which no longer have any open files in the editor (see `cleanUpAfterOpeningFile` in TypeScript's `ProjectService`). This optimization currently results in closing projects when only a template file is open because the template files are not sufficiently tracked (since they're non-TS files). A previous attempt to fix this issue was implemented in angular#1461 but does not work for solution-style `tsconfig` projects because when creating the external project, it only counts towards the `externalProjectRefCount` if the name of the tsconfig is `tsconfig.json` or `jsconfig.json` (See call to `getBaseConfigFileName` in `openExternalProjects`). Instead, this fix adds the template files to the project's `rootFiles`. This is sufficient to ensure the `hasOpenRef` check passes and the template's project is retained when navigating to a file that exists in a different project. Fixes angular#1623 Fixes angular#876
…service features The implementation of the ngcc queue for re-enabling project language service's is incorrect. It unconditionally removes projects from the queue when the ngcc process finishes even if it finished out of order and is waiting for the first project in the queue to finish. This results in later projects never getting the language service re-enabled when the earlier project(s) finally finish ngcc. This fix works towards stabilizing the extension for solution-style projects. Related to angular#876
…d projects When an external template is read, adds the template file to to the project which contains. This is necessary to keep the projects open when navigating away from HTML files. Since a `tsconfig` cannot express including non-TS files, we need another way to indicate the template files are considered part of the project. Note that this does not ensure that the project in question _directly_ contains the component file. That is, the project might just include the component file through the program rather than directly in the `include` glob of the `tsconfig`. This distinction is somewhat important because the TypeScript language service/server prefers projects which _directly_ contain the TS file (see `projectContainsInfoDirectly` in the TS codebase). What this means it that there can possibly be a different project used between the TS and HTML files. For example, in Nx projects, the referenced configs are `tsconfig.app.json` and `tsconfig.editor.json`. `tsconfig.app.json` comes first in the base `tsconfig.json` and contains the entry point of the app. `tsconfig.editor.json` contains the `**.ts` glob of all TS files. This means that `tsconfig.editor.json` will be preferred by the TS server for TS files but the `tsconfig.app.json` will be used for HTML files since it comes first and we cannot effectively express `projectContainsInfoDirectly` for HTML files. We could consider also updating the language server implementation to attempt to select the project to use for the template file based on which project contains its component file directly, using either the internal `project.projectContainsInfoDirectly` or as a workaround, check `project.isRoot(componentTsFile)`. Finally, keeping the projects open is hugely important in the solution style config case like Nx. When a TS file is opened, TypeScript will only retain `tsconfig.editor.json` and not `tsconfig.app.json`. However, if our extension does not also know to select `tsconfig.editor.json`, it will automatically select `tsconfig.app.json` since it is defined first in the `tsconfig.json` file. So we need to teach TS server that we are (1) interested in keeping projects open when there is an HTML file open and (2) optionally attempt to do this _only_ for projects that we know the TS language service will prioritize in TS files (i.e., attempt to only keep `tsconfig.editor.json` open and allow `tsconfig.app.json` to close) and prioritize that project for all requests. fixes angular/vscode-ng-language-service#1623 fixes angular/vscode-ng-language-service#876
…d projects When an external template is read, adds the template file to to the project which contains. This is necessary to keep the projects open when navigating away from HTML files. Since a `tsconfig` cannot express including non-TS files, we need another way to indicate the template files are considered part of the project. Note that this does not ensure that the project in question _directly_ contains the component file. That is, the project might just include the component file through the program rather than directly in the `include` glob of the `tsconfig`. This distinction is somewhat important because the TypeScript language service/server prefers projects which _directly_ contain the TS file (see `projectContainsInfoDirectly` in the TS codebase). What this means it that there can possibly be a different project used between the TS and HTML files. For example, in Nx projects, the referenced configs are `tsconfig.app.json` and `tsconfig.editor.json`. `tsconfig.app.json` comes first in the base `tsconfig.json` and contains the entry point of the app. `tsconfig.editor.json` contains the `**.ts` glob of all TS files. This means that `tsconfig.editor.json` will be preferred by the TS server for TS files but the `tsconfig.app.json` will be used for HTML files since it comes first and we cannot effectively express `projectContainsInfoDirectly` for HTML files. We could consider also updating the language server implementation to attempt to select the project to use for the template file based on which project contains its component file directly, using either the internal `project.projectContainsInfoDirectly` or as a workaround, check `project.isRoot(componentTsFile)`. Finally, keeping the projects open is hugely important in the solution style config case like Nx. When a TS file is opened, TypeScript will only retain `tsconfig.editor.json` and not `tsconfig.app.json`. However, if our extension does not also know to select `tsconfig.editor.json`, it will automatically select `tsconfig.app.json` since it is defined first in the `tsconfig.json` file. So we need to teach TS server that we are (1) interested in keeping projects open when there is an HTML file open and (2) optionally attempt to do this _only_ for projects that we know the TS language service will prioritize in TS files (i.e., attempt to only keep `tsconfig.editor.json` open and allow `tsconfig.app.json` to close) and prioritize that project for all requests. fixes angular/vscode-ng-language-service#1623 fixes angular/vscode-ng-language-service#876
…d projects When an external template is read, adds the template file to to the project which contains. This is necessary to keep the projects open when navigating away from HTML files. Since a `tsconfig` cannot express including non-TS files, we need another way to indicate the template files are considered part of the project. Note that this does not ensure that the project in question _directly_ contains the component file. That is, the project might just include the component file through the program rather than directly in the `include` glob of the `tsconfig`. This distinction is somewhat important because the TypeScript language service/server prefers projects which _directly_ contain the TS file (see `projectContainsInfoDirectly` in the TS codebase). What this means it that there can possibly be a different project used between the TS and HTML files. For example, in Nx projects, the referenced configs are `tsconfig.app.json` and `tsconfig.editor.json`. `tsconfig.app.json` comes first in the base `tsconfig.json` and contains the entry point of the app. `tsconfig.editor.json` contains the `**.ts` glob of all TS files. This means that `tsconfig.editor.json` will be preferred by the TS server for TS files but the `tsconfig.app.json` will be used for HTML files since it comes first and we cannot effectively express `projectContainsInfoDirectly` for HTML files. We could consider also updating the language server implementation to attempt to select the project to use for the template file based on which project contains its component file directly, using either the internal `project.projectContainsInfoDirectly` or as a workaround, check `project.isRoot(componentTsFile)`. Finally, keeping the projects open is hugely important in the solution style config case like Nx. When a TS file is opened, TypeScript will only retain `tsconfig.editor.json` and not `tsconfig.app.json`. However, if our extension does not also know to select `tsconfig.editor.json`, it will automatically select `tsconfig.app.json` since it is defined first in the `tsconfig.json` file. So we need to teach TS server that we are (1) interested in keeping projects open when there is an HTML file open and (2) optionally attempt to do this _only_ for projects that we know the TS language service will prioritize in TS files (i.e., attempt to only keep `tsconfig.editor.json` open and allow `tsconfig.app.json` to close) and prioritize that project for all requests. fixes angular/vscode-ng-language-service#1623 fixes angular/vscode-ng-language-service#876
…service features (#1627) The implementation of the ngcc queue for re-enabling project language service's is incorrect. It unconditionally removes projects from the queue when the ngcc process finishes even if it finished out of order and is waiting for the first project in the queue to finish. This results in later projects never getting the language service re-enabled when the earlier project(s) finally finish ngcc. This fix works towards stabilizing the extension for solution-style projects. Related to #876
…service features (#1627) The implementation of the ngcc queue for re-enabling project language service's is incorrect. It unconditionally removes projects from the queue when the ngcc process finishes even if it finished out of order and is waiting for the first project in the queue to finish. This results in later projects never getting the language service re-enabled when the earlier project(s) finally finish ngcc. This fix works towards stabilizing the extension for solution-style projects. Related to #876 (cherry picked from commit 5712ab8)
…d projects When an external template is read, adds the template file to to the project which contains. This is necessary to keep the projects open when navigating away from HTML files. Since a `tsconfig` cannot express including non-TS files, we need another way to indicate the template files are considered part of the project. Note that this does not ensure that the project in question _directly_ contains the component file. That is, the project might just include the component file through the program rather than directly in the `include` glob of the `tsconfig`. This distinction is somewhat important because the TypeScript language service/server prefers projects which _directly_ contain the TS file (see `projectContainsInfoDirectly` in the TS codebase). What this means it that there can possibly be a different project used between the TS and HTML files. For example, in Nx projects, the referenced configs are `tsconfig.app.json` and `tsconfig.editor.json`. `tsconfig.app.json` comes first in the base `tsconfig.json` and contains the entry point of the app. `tsconfig.editor.json` contains the `**.ts` glob of all TS files. This means that `tsconfig.editor.json` will be preferred by the TS server for TS files but the `tsconfig.app.json` will be used for HTML files since it comes first and we cannot effectively express `projectContainsInfoDirectly` for HTML files. We could consider also updating the language server implementation to attempt to select the project to use for the template file based on which project contains its component file directly, using either the internal `project.projectContainsInfoDirectly` or as a workaround, check `project.isRoot(componentTsFile)`. Finally, keeping the projects open is hugely important in the solution style config case like Nx. When a TS file is opened, TypeScript will only retain `tsconfig.editor.json` and not `tsconfig.app.json`. However, if our extension does not also know to select `tsconfig.editor.json`, it will automatically select `tsconfig.app.json` since it is defined first in the `tsconfig.json` file. So we need to teach TS server that we are (1) interested in keeping projects open when there is an HTML file open and (2) optionally attempt to do this _only_ for projects that we know the TS language service will prioritize in TS files (i.e., attempt to only keep `tsconfig.editor.json` open and allow `tsconfig.app.json` to close) and prioritize that project for all requests. fixes angular/vscode-ng-language-service#1623 fixes angular/vscode-ng-language-service#876
…d projects When an external template is read, adds the template file to to the project which contains. This is necessary to keep the projects open when navigating away from HTML files. Since a `tsconfig` cannot express including non-TS files, we need another way to indicate the template files are considered part of the project. Note that this does not ensure that the project in question _directly_ contains the component file. That is, the project might just include the component file through the program rather than directly in the `include` glob of the `tsconfig`. This distinction is somewhat important because the TypeScript language service/server prefers projects which _directly_ contain the TS file (see `projectContainsInfoDirectly` in the TS codebase). What this means it that there can possibly be a different project used between the TS and HTML files. For example, in Nx projects, the referenced configs are `tsconfig.app.json` and `tsconfig.editor.json`. `tsconfig.app.json` comes first in the base `tsconfig.json` and contains the entry point of the app. `tsconfig.editor.json` contains the `**.ts` glob of all TS files. This means that `tsconfig.editor.json` will be preferred by the TS server for TS files but the `tsconfig.app.json` will be used for HTML files since it comes first and we cannot effectively express `projectContainsInfoDirectly` for HTML files. We could consider also updating the language server implementation to attempt to select the project to use for the template file based on which project contains its component file directly, using either the internal `project.projectContainsInfoDirectly` or as a workaround, check `project.isRoot(componentTsFile)`. Finally, keeping the projects open is hugely important in the solution style config case like Nx. When a TS file is opened, TypeScript will only retain `tsconfig.editor.json` and not `tsconfig.app.json`. However, if our extension does not also know to select `tsconfig.editor.json`, it will automatically select `tsconfig.app.json` since it is defined first in the `tsconfig.json` file. So we need to teach TS server that we are (1) interested in keeping projects open when there is an HTML file open and (2) optionally attempt to do this _only_ for projects that we know the TS language service will prioritize in TS files (i.e., attempt to only keep `tsconfig.editor.json` open and allow `tsconfig.app.json` to close) and prioritize that project for all requests. fixes angular/vscode-ng-language-service#1623 fixes angular/vscode-ng-language-service#876
…d projects When an external template is read, adds the template file to to the project which contains. This is necessary to keep the projects open when navigating away from HTML files. Since a `tsconfig` cannot express including non-TS files, we need another way to indicate the template files are considered part of the project. Note that this does not ensure that the project in question _directly_ contains the component file. That is, the project might just include the component file through the program rather than directly in the `include` glob of the `tsconfig`. This distinction is somewhat important because the TypeScript language service/server prefers projects which _directly_ contain the TS file (see `projectContainsInfoDirectly` in the TS codebase). What this means it that there can possibly be a different project used between the TS and HTML files. For example, in Nx projects, the referenced configs are `tsconfig.app.json` and `tsconfig.editor.json`. `tsconfig.app.json` comes first in the base `tsconfig.json` and contains the entry point of the app. `tsconfig.editor.json` contains the `**.ts` glob of all TS files. This means that `tsconfig.editor.json` will be preferred by the TS server for TS files but the `tsconfig.app.json` will be used for HTML files since it comes first and we cannot effectively express `projectContainsInfoDirectly` for HTML files. We could consider also updating the language server implementation to attempt to select the project to use for the template file based on which project contains its component file directly, using either the internal `project.projectContainsInfoDirectly` or as a workaround, check `project.isRoot(componentTsFile)`. Finally, keeping the projects open is hugely important in the solution style config case like Nx. When a TS file is opened, TypeScript will only retain `tsconfig.editor.json` and not `tsconfig.app.json`. However, if our extension does not also know to select `tsconfig.editor.json`, it will automatically select `tsconfig.app.json` since it is defined first in the `tsconfig.json` file. So we need to teach TS server that we are (1) interested in keeping projects open when there is an HTML file open and (2) optionally attempt to do this _only_ for projects that we know the TS language service will prioritize in TS files (i.e., attempt to only keep `tsconfig.editor.json` open and allow `tsconfig.app.json` to close) and prioritize that project for all requests. fixes angular/vscode-ng-language-service#1623 fixes angular/vscode-ng-language-service#876
…d projects When an external template is read, adds the template file to to the project which contains. This is necessary to keep the projects open when navigating away from HTML files. Since a `tsconfig` cannot express including non-TS files, we need another way to indicate the template files are considered part of the project. Note that this does not ensure that the project in question _directly_ contains the component file. That is, the project might just include the component file through the program rather than directly in the `include` glob of the `tsconfig`. This distinction is somewhat important because the TypeScript language service/server prefers projects which _directly_ contain the TS file (see `projectContainsInfoDirectly` in the TS codebase). What this means it that there can possibly be a different project used between the TS and HTML files. For example, in Nx projects, the referenced configs are `tsconfig.app.json` and `tsconfig.editor.json`. `tsconfig.app.json` comes first in the base `tsconfig.json` and contains the entry point of the app. `tsconfig.editor.json` contains the `**.ts` glob of all TS files. This means that `tsconfig.editor.json` will be preferred by the TS server for TS files but the `tsconfig.app.json` will be used for HTML files since it comes first and we cannot effectively express `projectContainsInfoDirectly` for HTML files. We could consider also updating the language server implementation to attempt to select the project to use for the template file based on which project contains its component file directly, using either the internal `project.projectContainsInfoDirectly` or as a workaround, check `project.isRoot(componentTsFile)`. Finally, keeping the projects open is hugely important in the solution style config case like Nx. When a TS file is opened, TypeScript will only retain `tsconfig.editor.json` and not `tsconfig.app.json`. However, if our extension does not also know to select `tsconfig.editor.json`, it will automatically select `tsconfig.app.json` since it is defined first in the `tsconfig.json` file. So we need to teach TS server that we are (1) interested in keeping projects open when there is an HTML file open and (2) optionally attempt to do this _only_ for projects that we know the TS language service will prioritize in TS files (i.e., attempt to only keep `tsconfig.editor.json` open and allow `tsconfig.app.json` to close) and prioritize that project for all requests. fixes angular/vscode-ng-language-service#1623 fixes angular/vscode-ng-language-service#876
…d projects When an external template is read, adds the template file to to the project which contains. This is necessary to keep the projects open when navigating away from HTML files. Since a `tsconfig` cannot express including non-TS files, we need another way to indicate the template files are considered part of the project. Note that this does not ensure that the project in question _directly_ contains the component file. That is, the project might just include the component file through the program rather than directly in the `include` glob of the `tsconfig`. This distinction is somewhat important because the TypeScript language service/server prefers projects which _directly_ contain the TS file (see `projectContainsInfoDirectly` in the TS codebase). What this means it that there can possibly be a different project used between the TS and HTML files. For example, in Nx projects, the referenced configs are `tsconfig.app.json` and `tsconfig.editor.json`. `tsconfig.app.json` comes first in the base `tsconfig.json` and contains the entry point of the app. `tsconfig.editor.json` contains the `**.ts` glob of all TS files. This means that `tsconfig.editor.json` will be preferred by the TS server for TS files but the `tsconfig.app.json` will be used for HTML files since it comes first and we cannot effectively express `projectContainsInfoDirectly` for HTML files. We could consider also updating the language server implementation to attempt to select the project to use for the template file based on which project contains its component file directly, using either the internal `project.projectContainsInfoDirectly` or as a workaround, check `project.isRoot(componentTsFile)`. Finally, keeping the projects open is hugely important in the solution style config case like Nx. When a TS file is opened, TypeScript will only retain `tsconfig.editor.json` and not `tsconfig.app.json`. However, if our extension does not also know to select `tsconfig.editor.json`, it will automatically select `tsconfig.app.json` since it is defined first in the `tsconfig.json` file. So we need to teach TS server that we are (1) interested in keeping projects open when there is an HTML file open and (2) optionally attempt to do this _only_ for projects that we know the TS language service will prioritize in TS files (i.e., attempt to only keep `tsconfig.editor.json` open and allow `tsconfig.app.json` to close) and prioritize that project for all requests. fixes angular/vscode-ng-language-service#1623 fixes angular/vscode-ng-language-service#876
…d projects (#45601) When an external template is read, adds the template file to to the project which contains. This is necessary to keep the projects open when navigating away from HTML files. Since a `tsconfig` cannot express including non-TS files, we need another way to indicate the template files are considered part of the project. Note that this does not ensure that the project in question _directly_ contains the component file. That is, the project might just include the component file through the program rather than directly in the `include` glob of the `tsconfig`. This distinction is somewhat important because the TypeScript language service/server prefers projects which _directly_ contain the TS file (see `projectContainsInfoDirectly` in the TS codebase). What this means it that there can possibly be a different project used between the TS and HTML files. For example, in Nx projects, the referenced configs are `tsconfig.app.json` and `tsconfig.editor.json`. `tsconfig.app.json` comes first in the base `tsconfig.json` and contains the entry point of the app. `tsconfig.editor.json` contains the `**.ts` glob of all TS files. This means that `tsconfig.editor.json` will be preferred by the TS server for TS files but the `tsconfig.app.json` will be used for HTML files since it comes first and we cannot effectively express `projectContainsInfoDirectly` for HTML files. We could consider also updating the language server implementation to attempt to select the project to use for the template file based on which project contains its component file directly, using either the internal `project.projectContainsInfoDirectly` or as a workaround, check `project.isRoot(componentTsFile)`. Finally, keeping the projects open is hugely important in the solution style config case like Nx. When a TS file is opened, TypeScript will only retain `tsconfig.editor.json` and not `tsconfig.app.json`. However, if our extension does not also know to select `tsconfig.editor.json`, it will automatically select `tsconfig.app.json` since it is defined first in the `tsconfig.json` file. So we need to teach TS server that we are (1) interested in keeping projects open when there is an HTML file open and (2) optionally attempt to do this _only_ for projects that we know the TS language service will prioritize in TS files (i.e., attempt to only keep `tsconfig.editor.json` open and allow `tsconfig.app.json` to close) and prioritize that project for all requests. fixes angular/vscode-ng-language-service#1623 fixes angular/vscode-ng-language-service#876 PR Close #45601
…d projects (#45601) When an external template is read, adds the template file to to the project which contains. This is necessary to keep the projects open when navigating away from HTML files. Since a `tsconfig` cannot express including non-TS files, we need another way to indicate the template files are considered part of the project. Note that this does not ensure that the project in question _directly_ contains the component file. That is, the project might just include the component file through the program rather than directly in the `include` glob of the `tsconfig`. This distinction is somewhat important because the TypeScript language service/server prefers projects which _directly_ contain the TS file (see `projectContainsInfoDirectly` in the TS codebase). What this means it that there can possibly be a different project used between the TS and HTML files. For example, in Nx projects, the referenced configs are `tsconfig.app.json` and `tsconfig.editor.json`. `tsconfig.app.json` comes first in the base `tsconfig.json` and contains the entry point of the app. `tsconfig.editor.json` contains the `**.ts` glob of all TS files. This means that `tsconfig.editor.json` will be preferred by the TS server for TS files but the `tsconfig.app.json` will be used for HTML files since it comes first and we cannot effectively express `projectContainsInfoDirectly` for HTML files. We could consider also updating the language server implementation to attempt to select the project to use for the template file based on which project contains its component file directly, using either the internal `project.projectContainsInfoDirectly` or as a workaround, check `project.isRoot(componentTsFile)`. Finally, keeping the projects open is hugely important in the solution style config case like Nx. When a TS file is opened, TypeScript will only retain `tsconfig.editor.json` and not `tsconfig.app.json`. However, if our extension does not also know to select `tsconfig.editor.json`, it will automatically select `tsconfig.app.json` since it is defined first in the `tsconfig.json` file. So we need to teach TS server that we are (1) interested in keeping projects open when there is an HTML file open and (2) optionally attempt to do this _only_ for projects that we know the TS language service will prioritize in TS files (i.e., attempt to only keep `tsconfig.editor.json` open and allow `tsconfig.app.json` to close) and prioritize that project for all requests. fixes angular/vscode-ng-language-service#1623 fixes angular/vscode-ng-language-service#876 PR Close #45601
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. |
Issue Type: Bug
Recently, I can no longer get suggestions of Angular HTML attributes and variable suggestions. Also, it no longer shows errors as it used to such as when I bound to a non-existant variable. So basically I have no Angular support in my HTML templates any longer.
System Info
flash_3d: enabled
flash_stage3d: enabled
flash_stage3d_baseline: enabled
gpu_compositing: enabled
metal: disabled_off
multiple_raster_threads: enabled_on
oop_rasterization: disabled_off
protected_video_decode: unavailable_off
rasterization: enabled
skia_renderer: disabled_off_ok
video_decode: enabled
viz_display_compositor: enabled_on
viz_hit_test_surface_layer: disabled_off_ok
webgl: enabled
webgl2: enabled
The text was updated successfully, but these errors were encountered: