-
Notifications
You must be signed in to change notification settings - Fork 24.8k
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
feat(language-service): Allow auto-imports of a pipe via quick fix when its selector is used. #48354
Conversation
de4e81e
to
e5fc833
Compare
ad8fb05
to
49787c1
Compare
@atscott Just want to keep this on your radar -- no rush though. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
reviewed-for: fw-language-service
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
reviewed-for: language-service
Back to @alxhub with a new design for |
Currently, the auto-import tests are very difficult to debug, because the `expect`ations are buried several function calls deep, and also because the multi-line replacements are hard to deal with. The auto-import tests now use a different approach, which can be easily debugged from the failure message. In addition, several new tests have been added to cover more cases.
`MetadataReaderWithIndex.getKnown` currently returns an iterator. It will be easier to work with for upcoming usages if it returns an array instead.
packages/compiler-cli/src/ngtsc/metadata/src/ng_module_index.ts
Outdated
Show resolved
Hide resolved
packages/compiler-cli/src/ngtsc/metadata/src/ng_module_index.ts
Outdated
Show resolved
Hide resolved
…suggest re-exports. NgModules can re-export other NgModules, which transitively includes all traits exported by the re-exported NgModule. We want to be able to suggest *all* re-exports of a component when trying to auto-import it. Previously, we used an approximation when importing from NgModules: we looked at a Component's metadata, and just imported the declaring NgModule. However, this is not technically correct -- the declaring NgModule it is not necessarily the same one that exports it for the current scope. (Indeed, there could be multiple re-exports!) As a replacement, I have implemented a more general solution. This PR introduces a new class on the template type checker, called `NgModuleIndex`. When queried, it conducts a depth-first-search over the NgModule import/export graph, in order to find all NgModules anywhere in the current dependency graph, as well as all exports of those NgModules. This allows the language service to suggest all of the re-exports, in addition to the original export.
…en its selector is used, both directly and via reexports. A previous PR introduced a new compiler abstraction that tracks *all* known exports and re-exports of Angular traits. This PR harnesses that abstraction in the language service, in order to allow automatic imports of pipes.
caretaker: the failing windows CI job appears to be unrelated. |
This PR was merged into the repository by commit 4ae384f. |
…suggest re-exports. (#48354) NgModules can re-export other NgModules, which transitively includes all traits exported by the re-exported NgModule. We want to be able to suggest *all* re-exports of a component when trying to auto-import it. Previously, we used an approximation when importing from NgModules: we looked at a Component's metadata, and just imported the declaring NgModule. However, this is not technically correct -- the declaring NgModule it is not necessarily the same one that exports it for the current scope. (Indeed, there could be multiple re-exports!) As a replacement, I have implemented a more general solution. This PR introduces a new class on the template type checker, called `NgModuleIndex`. When queried, it conducts a depth-first-search over the NgModule import/export graph, in order to find all NgModules anywhere in the current dependency graph, as well as all exports of those NgModules. This allows the language service to suggest all of the re-exports, in addition to the original export. PR Close #48354
…en its selector is used, both directly and via reexports. (#48354) A previous PR introduced a new compiler abstraction that tracks *all* known exports and re-exports of Angular traits. This PR harnesses that abstraction in the language service, in order to allow automatic imports of pipes. PR Close #48354
…ngular#48354) Currently, the auto-import tests are very difficult to debug, because the `expect`ations are buried several function calls deep, and also because the multi-line replacements are hard to deal with. The auto-import tests now use a different approach, which can be easily debugged from the failure message. In addition, several new tests have been added to cover more cases. PR Close angular#48354
…gular#48354) `MetadataReaderWithIndex.getKnown` currently returns an iterator. It will be easier to work with for upcoming usages if it returns an array instead. PR Close angular#48354
…suggest re-exports. (angular#48354) NgModules can re-export other NgModules, which transitively includes all traits exported by the re-exported NgModule. We want to be able to suggest *all* re-exports of a component when trying to auto-import it. Previously, we used an approximation when importing from NgModules: we looked at a Component's metadata, and just imported the declaring NgModule. However, this is not technically correct -- the declaring NgModule it is not necessarily the same one that exports it for the current scope. (Indeed, there could be multiple re-exports!) As a replacement, I have implemented a more general solution. This PR introduces a new class on the template type checker, called `NgModuleIndex`. When queried, it conducts a depth-first-search over the NgModule import/export graph, in order to find all NgModules anywhere in the current dependency graph, as well as all exports of those NgModules. This allows the language service to suggest all of the re-exports, in addition to the original export. PR Close angular#48354
…en its selector is used, both directly and via reexports. (angular#48354) A previous PR introduced a new compiler abstraction that tracks *all* known exports and re-exports of Angular traits. This PR harnesses that abstraction in the language service, in order to allow automatic imports of pipes. PR Close angular#48354
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. |
Four commits, as below:
refactor(language-service): Improve the quick fix auto-import tests.
Currently, the auto-import tests are very difficult to debug, because the
expect
ations are buried several function calls deep, and also because the multi-line replacements are hard to deal with. The auto-import tests now use a different approach, which can be easily debugged from the failure message. In addition, several new tests have been added to cover more cases.refactor(compiler-cli): Make
getKnown
return an array of nodes.MetadataReaderWithIndex.getKnown
currently returns an iterator. It will be easier to work with for upcoming usages if it returns an array instead.feat(language-service): Introduce a new NgModuleIndex, and use it to suggest re-exports.
NgModules can re-export other NgModules, which transitively includes all traits exported by the re-exported NgModule. We want to be able to suggest all re-exports of a component when trying to auto-import it.
Previously, we used an approximation when importing from NgModules: we looked at a Component's metadata, and just imported the declaring NgModule. However, this is not technically correct -- the declaring NgModule it is not necessarily the same one that exports it for the current scope. (Indeed, there could be multiple re-exports!) As a replacement, I have implemented a more general solution.
This PR introduces a new class on the template type checker, called
NgModuleIndex
. When queried, it conducts a depth-first-search over the NgModule import/export graph, in order to find all NgModules anywhere in the current dependency graph, as well as all exports of those NgModules. This allows the language service to suggest all of the re-exports, in addition to the original export.feat(language-service): Allow auto-imports of a pipe via quick fix when its selector is used, both directly and via reexports.
A previous PR introduced a new compiler abstraction that tracks all known exports and re-exports of Angular traits. This PR harnesses that abstraction in the language service, in order to allow automatic imports of pipes.