Skip to content

Conversation

@giner
Copy link

@giner giner commented Nov 25, 2025

Correctly identify different types of terraform files:

  • terraform-vars
  • terraform-stack
  • terraform-deploy
  • terraform-search

Fixes:

Refs:

Correctly identify different types of terraform files:
- terraform-vars
- terraform-stack
- terraform-deploy
- terraform-search

Fixes:
- hashicorp/terraform-ls#1838

Refs:
- https://github.com/hashicorp/terraform-ls/blob/c20eef80eac1d158e0fc45d7f6de23602104a3f8/docs/language-clients.md#language-ids
@giner giner force-pushed the stas/add_support_for_terraform-vars_terraform-stack_terraform-deploy_terraform-search branch from afdce37 to 10a20fd Compare November 25, 2025 13:43
@dimbleby
Copy link
Contributor

dimbleby commented Nov 25, 2025

this is kinda silly, isn't it?

The terraform language server has made a dubious choice that it wants 6 (six!) different language identifiers, and now all editors are expected to go along with that. I don't love it.

Why doesn't the terraform language server accept the language identifier "terraform", and look at the suffix itself (in the uri) to deal with these variations? Did anyone try asking them that already?

Edit: 5, not 6. But the point stands.

@giner
Copy link
Author

giner commented Nov 25, 2025

I found discussions related to the implementation where different options were considered (warning: a lot of comments to go through):

@dimbleby
Copy link
Contributor

I don't see different options being considered in those discussions

@giner
Copy link
Author

giner commented Nov 25, 2025

You are right, I've read again carefully and found this one as the most relevant comment (not options but justification):

@giner
Copy link
Author

giner commented Nov 25, 2025

Also, thinking about the end user UX setting language ID by the client makes sense as there are cases when file extension is not present, for example, when I set file type at runtime (:set ft=terraform-vars).

@dimbleby
Copy link
Contributor

Treating terraform as though it were five separate languages strikes me as absurd. It's barely even one! - it's all HCL

I am not aware of any other language or language server that expects such fine-grained divisions eg so far as I know c is c, whether it is .c or .h.

In a world where this particular language server implementation gets to set the rules, your pull request makes sense. But that does not seem like a reasonable world. What if someone else wants to write a language server for terraform? are they too obliged to follow this convention?

I'll sit on this for a bit, I don't know how much trouble it is really worth.

If you wanted to head over to hashicorp/terraform-ls#1838 and suggest that they could fix this by not making such demands of every text editor, that'd be great.

@giner
Copy link
Author

giner commented Nov 25, 2025

The decision on their side is made and it was made long time ago. I see no reason for them to revisit it now and I don't see myself trying to convince them, not without strong arguments on why they have to break backwards compatibility now. I'm hoping for the language server for tf and tofu (which are my primary tools these days) just work andI created this PR with a hope to fix something which is bothering me for quite some time now. If you see another sensible way to fix the issue I'm all for it.

@dimbleby
Copy link
Contributor

the reason for them to revisit it now would be that it was a poor decision which has negative consequences

it's not just users of this plugin - as I say, every editor is being asked to go along with this. I see emacs users in that thread too.

fwiw I personally don't use this plugin at all any more - most of it has been absorbed into vim / neovim. And for better or worse, the author of this proliferation of filetypes has persuaded them to go to two (though not yet five!): neovim/neovim#19417

So you could likely fix the issue simply by not using this plugin

@giner
Copy link
Author

giner commented Nov 25, 2025

Thank for the link. I use vim, not neovim, so I still need the plugin.

@dimbleby
Copy link
Contributor

keep following the links, it's all in vim too

@giner
Copy link
Author

giner commented Nov 25, 2025

I've just tried removing the plugin and yes, ftdetect works but no syntax highlighting and I'm not sure about indent

@dimbleby
Copy link
Contributor

dimbleby commented Nov 25, 2025

I think I'd be more inclined to accept a pull request that left all the not-just-plain-terraform files as hcl - which should mostly be a no-op, since they end in .hcl anyway and that is what we are doing today.

Then the only change that would be needed would be to treat .tfvars as hcl instead of as terraform.

That gives up on this language server being useful for tfvars files when used with this plugin: but apparently that is the case anyway so no great loss.

If and when someone wants to make the case that terraform really is five separate (but identical) languages we can have this conversation again.

@giner
Copy link
Author

giner commented Nov 25, 2025

That gives up on this language server being useful for tfvars files when used with this plugin: but apparently that is the case anyway so no great loss.

Processing tfvars by the language server is exactly what I need with all go-to-definition and autocomplete working.

That gives up on this language server being useful for tfvars files when used with this plugin: but apparently that is the case anyway so no great loss.

At this point I don't care about terraform-stack, terraform-deploy and terraform-search, I've added them for completeness because I found them in the docs. I can remove these it this works for you.

@giner
Copy link
Author

giner commented Nov 27, 2025

@dimbleby any thoughts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants