You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The experience in the editor is important. Users want to get feedback in the editor in real-time than detected by CI after pushing to the branch. TFLint has provided an experimental language server, but I think it's not enough yet.
The LSP support has the following issues:
There are no out-of-the-box extensions. You need an installable package like vscode-terraform.
The language server cannot analyze repositories that have multiple workspaces correctly.
The language server performance has not been tested.
For the first issue, you can either publish a new package or consider how to embed it into vscode-terraform. However, there are many things to consider because TFLint's language server is not able to used in vscode-terraform. I'm thinking of starting by publishing my own package.
The second issue will be solved by fixing #1355. When rewriting the module loader, it is necessary to design not only a linter but also a language server.
The last issue is important when considering deep checking, such as in the AWS ruleset. I haven't really seen how the current language server works for deep checking, but the experience is probably terrible. A language server that is slow to respond will make the development experience worse. The lifecycle of a language server is long enough, unlike a linter, so you can use the cache more aggressively. It may be possible to parallelize the inspections using goroutine.
In addition to these issues, the language server may be able to provide great functionality. For example, the AWS ruleset has enum candidates that you might use as a response to a completion request. In this way, I believe that improving LSP support can make a contribution to improving the developer experience.
The text was updated successfully, but these errors were encountered:
The experience in the editor is important. Users want to get feedback in the editor in real-time than detected by CI after pushing to the branch. TFLint has provided an experimental language server, but I think it's not enough yet.
The LSP support has the following issues:
For the first issue, you can either publish a new package or consider how to embed it into vscode-terraform. However, there are many things to consider because TFLint's language server is not able to used in vscode-terraform. I'm thinking of starting by publishing my own package.
The second issue will be solved by fixing #1355. When rewriting the module loader, it is necessary to design not only a linter but also a language server.
The last issue is important when considering deep checking, such as in the AWS ruleset. I haven't really seen how the current language server works for deep checking, but the experience is probably terrible. A language server that is slow to respond will make the development experience worse. The lifecycle of a language server is long enough, unlike a linter, so you can use the cache more aggressively. It may be possible to parallelize the inspections using goroutine.
In addition to these issues, the language server may be able to provide great functionality. For example, the AWS ruleset has enum candidates that you might use as a response to a completion request. In this way, I believe that improving LSP support can make a contribution to improving the developer experience.
The text was updated successfully, but these errors were encountered: