refactor: Introduce PathContext and DecoderContext #92
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.
Summary
As it is usually the case with refactoring PRs, the diff is not small. However I tried to separate all changes into some logical steps per commits in the log.
The overall intention is to bring the main
Decoder
API closer to LSP methods and move some lower-level APIs into a newreference
package. This then allows us to reduce the footprint of handlers in LS.All these changes allow us to reuse a single instance of the decoder in LS, as demonstrated in hashicorp/terraform-ls#689 which aids readability.
Motivation
All this is mainly to enable future Terraform LS module-related work as described in hashicorp/vscode-terraform#715 Most of this work can now be done within this library, as opposed to LS itself, such that future other language servers can benefit from it.
New Concept of a Path
A concept of "path" is introduced, where path represents a path with parsed files of a particular single language ID (such as
*.tf
in case of Terraform). Relatedly the "context" required for the decoder is now exposed more systematically viaPathContext
(for path-dependent context) andDecoderContext
for global/shared settings. This provides more flexibility and cleaner API than a setter for each option.Generalized Code Lens
It also introduces a more generalized concept of code lens, as represented by this interface:
In theory we could introduce some kind of stdlib of code lenses which are useful for any HCL2 config, but the trouble is that the "command" interface is still
very loosely definedundefined by LSP itself, there's very little convention and so it's unclear how useful would such stdlib be at this point.However this can pave a way for a similar generalized API for code actions in the future.
Snapshots of the generated docs probably best illustrate the difference.
Before
https://pkg.go.dev/github.com/hashicorp/hcl-lang@v0.0.0-20211021151402-2f992812c925/decoder#pkg-index
type Decoder
After
https://pkg.go.dev/github.com/hashicorp/hcl-lang@v0.0.0-20211029104910-0a2d253a116f/decoder
https://pkg.go.dev/github.com/hashicorp/hcl-lang@v0.0.0-20211029104910-0a2d253a116f/reference
type Decoder
type PathDecoder
Notably the new reference-related methods expose more minimal structs representing just necessary details about references:
decoder.ReferenceOrigin
decoder.ReferenceTarget
which make them far more suitable to also represent cross-path references.