Module View Provider #746
Merged
Module View Provider #746
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jpogran
force-pushed
the
f-module-view
branch
6 times, most recently
from
b8ea335 to
8ef2037
Compare
jpogran
force-pushed
the
f-module-view
branch
3 times, most recently
from
938d2a9 to
58b857f
Compare
jpogran
added a commit
to hashicorp/terraform-ls
that referenced
this pull request
Sep 13, 2021
Adds a handler to return a list of modules used by a given module path. Each module returned shows the module name, version, documentation link and what type of module it is (local, github, or terraform registry). It also detects if a module has nested modules, and adds them in the `DependentModules` property. This is meant to be used in tandem with hashicorp/vscode-terraform#746
jpogran
force-pushed
the
f-module-view
branch
from
58b857f to
5950a72
Compare
radeksimko
reviewed
Sep 15, 2021
There was a problem hiding this comment.
I left you some comments in-line, mostly naming related, I reckon we should probably first resolve #771 and leverage the code here as well to avoid reintroducing the same bug.
jpogran
force-pushed
the
f-module-view
branch
6 times, most recently
from
c4a63b0 to
a18a79e
Compare
jpogran
added a commit
to hashicorp/terraform-ls
that referenced
this pull request
Sep 22, 2021
Adds a handler to return a list of modules used by a given module path. Each module returned shows the module name, version, documentation link and what type of module it is (local, github, or terraform registry). It also detects if a module has nested modules, and adds them in the `DependentModules` property. This is meant to be used in tandem with hashicorp/vscode-terraform#746
radeksimko
reviewed
Sep 23, 2021
radeksimko
reviewed
Sep 23, 2021
There was a problem hiding this comment.
This looks pretty good to me, aside from that minor gitlab comment and from reflecting any remaining API changes in hashicorp/terraform-ls#63 here
jpogran
added a commit
to hashicorp/terraform-ls
that referenced
this pull request
Sep 23, 2021
Adds a handler to return a list of modules used by a given module path. Each module returned shows the module name, version, documentation link and what type of module it is (local, github, or terraform registry). It also detects if a module has nested modules, and adds them in the `DependentModules` property. This is meant to be used in tandem with hashicorp/vscode-terraform#746
This adds a new view to the Explorer view container in the activity bar that shows a list of modules referenced in the module opened. Each module is styled based on its type, and will show dependent modules that can be expanded. It also introduces two new commands, `refresh` and `open documentation`, that are tied to the view and can be used in the view title bar as well as in context menus for each module. This view will be only active when the extension activates, and will only display information when a module is open that references modules. If no modules are found, a note is left in the window. This also introduces a new approach to organizing the code in feature files instead of entirely inside the extension.ts file.
jpogran
force-pushed
the
f-module-view
branch
from
a18a79e to
e914098
Compare
jpogran
added a commit
to hashicorp/terraform-ls
that referenced
this pull request
Sep 23, 2021
Adds a handler to return a list of modules used by a given module path. Each module returned shows the module name, version, documentation link and what type of module it is (local, github, or terraform registry). It also detects if a module has nested modules, and adds them in the `DependentModules` property. This is meant to be used in tandem with hashicorp/vscode-terraform#746 TODO: It is technically incorrect to use the package hashicorp/terraform-registry-address here as it is written to parse Terraform provider addresses and may not work correctly on Terraform module addresses. The proper approach is to create a new parsing library that is dedicated to parsing these kinds of addresses correctly, by re-using the logic defined in the authorative source: hashicorp/terraform/internal/addrs/module_source.go. However this works enough for now to identify module types for display in vscode-terraform.
jpogran
added a commit
to hashicorp/terraform-ls
that referenced
this pull request
Sep 23, 2021
Adds a handler to return a list of modules used by a given module path. Each module returned shows the module name, version, documentation link and what type of module it is (local, github, or terraform registry). It also detects if a module has nested modules, and adds them in the `DependentModules` property. This is meant to be used in tandem with hashicorp/vscode-terraform#746 TODO: It is technically incorrect to use the package hashicorp/terraform-registry-address here as it is written to parse Terraform provider addresses and may not work correctly on Terraform module addresses. The proper approach is to create a new parsing library that is dedicated to parsing these kinds of addresses correctly, by re-using the logic defined in the authorative source: hashicorp/terraform/internal/addrs/module_source.go. However this works enough for now to identify module types for display in vscode-terraform. This also increases the CI timeout for the build process. We think the introduction of go-getter inflated the dependency tree and adds more time. At the moment it is more economical to eat the build time than take the engineering time to copy the methods needed to detect the correct module sources.
jpogran
added a commit
to hashicorp/terraform-ls
that referenced
this pull request
Sep 23, 2021
Adds a handler to return a list of modules used by a given module path. Each module returned shows the module name, version, documentation link and what type of module it is (local, github, or terraform registry). It also detects if a module has nested modules, and adds them in the `DependentModules` property. This is meant to be used in tandem with hashicorp/vscode-terraform#746 TODO: It is technically incorrect to use the package hashicorp/terraform-registry-address here as it is written to parse Terraform provider addresses and may not work correctly on Terraform module addresses. The proper approach is to create a new parsing library that is dedicated to parsing these kinds of addresses correctly, by re-using the logic defined in the authorative source: hashicorp/terraform/internal/addrs/module_source.go. However this works enough for now to identify module types for display in vscode-terraform. This also increases the CI timeout for the build process. We think the introduction of go-getter inflated the dependency tree and adds more time. At the moment it is more economical to eat the build time than take the engineering time to copy the methods needed to detect the correct module sources.
jpogran
added a commit
to hashicorp/terraform-ls
that referenced
this pull request
Sep 23, 2021
Adds a handler to return a list of modules used by a given module path. Each module returned shows the module name, version, documentation link and what type of module it is (local, github, or terraform registry). It also detects if a module has nested modules, and adds them in the `DependentModules` property. This is meant to be used in tandem with hashicorp/vscode-terraform#746 TODO: It is technically incorrect to use the package hashicorp/terraform-registry-address here as it is written to parse Terraform provider addresses and may not work correctly on Terraform module addresses. The proper approach is to create a new parsing library that is dedicated to parsing these kinds of addresses correctly, by re-using the logic defined in the authorative source: hashicorp/terraform/internal/addrs/module_source.go. However this works enough for now to identify module types for display in vscode-terraform. This also increases the CI timeout for the build process. We think the introduction of go-getter inflated the dependency tree and adds more time. At the moment it is more economical to eat the build time than take the engineering time to copy the methods needed to detect the correct module sources.
|
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Module view inside Explorer view container, with nested modules displayed
Documentation Link
Closes #698
Needs hashicorp/terraform-ls#632