Skip to content
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

Terraform Version LanguageStatusItem #1325

Merged
merged 4 commits into from
Jan 23, 2023
Merged

Terraform Version LanguageStatusItem #1325

merged 4 commits into from
Jan 23, 2023

Conversation

jpogran
Copy link
Contributor

@jpogran jpogran commented Jan 17, 2023

This uses a StaticFeature to provide a LanguageStatusItem that displays the version of terraform that terraform-ls knows about.

tf_version_statusitem

@jpogran jpogran self-assigned this Jan 17, 2023
@jpogran jpogran linked an issue Jan 17, 2023 that may be closed by this pull request
2 tasks
This uses a StaticFeature to provide a LanguageStatusItem that displays the version of terraform that terraform-ls knows about.
@jpogran jpogran marked this pull request as ready for review January 18, 2023 17:15
@jpogran jpogran requested a review from a team as a code owner January 18, 2023 17:15
Copy link
Member

@dbanck dbanck left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work! Also looks great for dev versions.
CleanShot 2023-01-19 at 17 41 52@2x

I've two questions about the case when no Terraform version can be determined.

src/terraform.ts Outdated Show resolved Hide resolved

try {
const response = await terraform.terraformVersion(moduleDir.toString(), this.client, this.reporter);
this.terraformStatus.text = response.discovered_version;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do we want to display if no version was discovered?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure here. If I don't set it, its an empty space. I could replace with N/A or Not found but it looks odd.

You can't hide a LanguageStatusItem that's been created like you can with a StatusBarItem, so you are left with it there after initialization. The alternative is to not create it unless a version comes back, but that does not account for the scenario when one directory has a terraform binary available to query, and another doesn't.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the combination of what you're proposing may work best, i.e. not create the LanguageStatusItem at all if the version is unknown and display something like unknown if it changes to unknown as part of the refresh.

FWIW unlike the constraint, we don't really re-discover the installed version on LS side at the moment, so the scenario with unknown basically can not happen, for now. hashicorp/terraform-ls#69

Copy link
Member

@radeksimko radeksimko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll leave review of the implementation details to Daniel, I have just two mostly UX related questions:

  1. Do we know if there's any convention on the location and content of such a "status item"? Reason I'm asking is because the official Go extension puts the Go version on the left side and it appears as one "item" Screenshot 2023-01-20 at 10 53 45
    They have two additional items in the status bar on the right 2023-01-20 10 54 43 I'm not sure if all these things are relevant for us, now or later, and I'm neither sure if other extensions follow what Go does too, just trying to get a sense of "what's common" in VS Code and what and where does the user will expect to see.
  2. Are we intentionally leaving out the discovered Terraform version constraint? I thought in the initial issue that it would be useful to display, but I can see how limited space we're working with, so I'd be fine with leaving it out - just seeking ack that this was intentional rather than accidental. 😃

@radeksimko radeksimko added the enhancement New feature or request label Jan 20, 2023
@jpogran
Copy link
Contributor Author

jpogran commented Jan 20, 2023

  1. Do we know if there's any convention on the location and content of such a "status item"?

Yes, there are now two "status item" items: StatusBarItem and LanguageStatusItem. StatusBarItems can be placed anywhere in the status bar, and originally was the only way to indicate status. You could create as many as you wanted and put whatever text you wanted in it, but were encouraged to be a good extension author and not get carried away. LanguageStatusItem is the newer item, and it only appears next to the Language identifier and there is only "one" of them in the sense there is only one {} shown. You can add many LanguageStatusItems to it, and it will stack them together. A user can choose to pin one or more of these in the stack, or choose not to, which solves the clutter that StatusBarItem allows.

The Go extension uses StatusBarItems and chooses to put it to the left for versions and right for updating Go. The placement is a design decision on their part. Use of the left side is discouraged as it's seen as "core functionality", but there is no restriction on placement.

I chose LanguageStatusItem because of the standardized and centralized location for many different pieces of information, with it's built in support for status indication and error notification. You can look at the TypeScript and JSON extensions for examples.

  1. Are we intentionally leaving out the discovered Terraform version constraint?

Not intentional. While it appears we don't have much "space", we have the ability to add a new LanguageStatusItem for each piece of information, which can show status (error, busy, etc) individually. This is what StatusBarItem can't do: keep multiple sets of information together in a concise and configurable form.

resolved

I can't simulate it in the gif, but imagine the author opening the file with the resolved and required versions pinned. The required version shows up, but the resolved version shows an error because the required version is incorrect. The {} will shake and show a warning flag, indicating there is an error resolving the constraint.

Copy link
Member

@radeksimko radeksimko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, just one minor wording suggestion.

src/features/terraformVersion.ts Outdated Show resolved Hide resolved
Copy link
Member

@dbanck dbanck left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍

Co-authored-by: Radek Simko <radek.simko@gmail.com>
@jpogran jpogran merged commit 489a1e0 into main Jan 23, 2023
@jpogran jpogran deleted the terraform-version-status branch January 23, 2023 16:59
@github-actions
Copy link

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.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 23, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Display Terraform path, version and constraint in the status bar
3 participants