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

feat: Terraform 0.12 support (was hcl2 support) #157

Open
astorath opened this issue Mar 1, 2019 · 68 comments

Comments

Projects
None yet
@astorath
Copy link

commented Mar 1, 2019

Hi!

Is there any plans to implement hcl2 support?

@dhdersch

This comment has been minimized.

Copy link

commented Mar 13, 2019

+1 with the release of the Terraform 0.12 Beta, this feature would be extremely beneficial.

@CKost

This comment has been minimized.

Copy link

commented Mar 13, 2019

+1, this feature would be exceedingly useful

@mauve

This comment has been minimized.

Copy link
Owner

commented Mar 13, 2019

HCL support is currently implemented by taking the HCL Go-library and feeding it through GopherJS to get a (very raw) JavaScript library (refer https://github.com/mauve/vscode-terraform/tree/master/hcl-hil) and then made into something useable in this part of the codebase: build.ts.

I do not have time myself to look into this right now but if somebody wants to give it a try, that is where you need to change stuff.

@captaintino

This comment has been minimized.

Copy link

commented Mar 13, 2019

+1 I think this feature would really be helpful.

@d-helios

This comment has been minimized.

Copy link

commented Apr 16, 2019

+1

@mauve mauve added the help wanted label Apr 30, 2019

@mauve

This comment has been minimized.

Copy link
Owner

commented Apr 30, 2019

I really would like to add this feature but I cannot do it myself as I do not have time, I can help somebody if they want to do it. I have tried to get Hashicorp to take over the project but they are not interested.

@jnicholls

This comment has been minimized.

Copy link

commented May 8, 2019

This does seem somewhat of an easy transition to hcl2. The API is different, but overall I think still embeddable in the same way. @mauve I will take a stab at it and let you know if I have questions; it will most likely involve the build & test process initially :) EDIT: Build and test was a snap.

@mauve

This comment has been minimized.

Copy link
Owner

commented May 8, 2019

@jnicholls Thanks for tackling this.

If the hcl2 library is capable of parsing hcl1 then I recommend just replacing it. in the meantime you might also want to replace the syntax-highlighting tmLanguage files with the official files from the hcl2 repo.

The data flow right now is hcl-hil.parseHcl -> build.ts -> FileIndex.ts, the only reason why build.ts was needed was because the output of parseHcl requires a lot of munging to be usuable. However now that you are touching this I can recommend trying to simplify everything at the same time.

The only reason why I added build.ts and did the complicated post-parsing of AST from the hcl-hil was because 1) emitting the all the types from the GoLang library would create a too large JS library, 2) I couldn't figure out how to add new types in Go and emit them to JS (🤣 and didn't want to spend too much time on trying to get it to work).

However I recommend that you might save yourself a lot of time if you make the Go-code emit something much closer to what FileIndex.ts wants it to be, that way you can remove build.ts.

@jnicholls

This comment has been minimized.

Copy link

commented May 8, 2019

Well, it looks like the AST is 100% different, haha. But, I think it is actually friendlier, and it's much more strongly typed. See https://github.com/hashicorp/hcl2/blob/master/hcl/hclsyntax/spec.md. I think we can walk this AST and provide a good result from parseHcl, but nothing really matches what you're looking for in FileIndex in terms of Sections and References, and thus walking the AST (albeit it will be quite different) is still necessary. I think we can do that walk on the Go side and get rid of build as well as parseHilWithPosition and bring back from parseHcl the desired sections, references and diagnostics if any (diagnostics and ranges are native to the hclsyntax parser, which is great, multiple diagnostics may be returned from a single pass to the parser, though your FileIndex interface only expects to return a single one). The diagnostics also will have did you mean ...? suggestions.

@mauve

This comment has been minimized.

Copy link
Owner

commented May 9, 2019

In the old HCL library a section refers to any top-level entity, for example: locals, terraform, variable, resource or data. This is also what I use Section for in the plugin. However the HCL library uses sections also for nested propertiers (the group in resource a b { group { a = b } }), this is different in the the plugin (where are properties (group or not) are just mapped to Properties).

The references were never part of the AST directly but they are extracted by build.ts after performing a parseHilWithPosition and traversing the AST produced by that call.

Currently FileIndex can have several diagnostics (FileIndex.diagnostics: Diagnostic[] = []), however as the parseHcl function in the HCL1 library fails when it encounters the first error FileIndex.fromString() (which uses build()) only returns a single Diagnostic if parsing fails. However as build() calls parseHilWithPosition() several times we have the chance to collect many HIL errors and add them to FIleIndex.diagnostics if we encounter them.

The current code assumes that FileIndex.fromString() returns either a FileIndex or a Diagnostic and a FileIndex with FileIndex.diagnostics populated if parsing succeeded (but with errors or warnings). If the HCL2 library is now finally able to recover and doesn't give up after encountering the first error I assume that you can just continue and using the code as before (but maybe changing FileIndex.fromString() and build() to return multiple diagnostics in case parsing fails.

@mauve

This comment has been minimized.

Copy link
Owner

commented May 9, 2019

If the HCL2 library is also able to recover from parse-errors and continue parsing we can also start using it more in the auto-completion provider. If you can find a HCL2 go function which (given a position in the text-document, or a position in the AST) gives us a list of possible next-tokens, that would be really awesome.

@jnicholls

This comment has been minimized.

Copy link

commented May 9, 2019

HCL2 will not continue parsing unfortunately. As evidenced by:

func TestParse(t *testing.T) {
	source := `variable "aws_access_key"
		default     = "xxx"
		description = "Amazon AWS Access Key"
	 }

	 variable "aws_secret_key" {
		 default    = "xxx"
		 description = "Amazon AWS Secret Key"
	 }`
	file, diagnostics := hclsyntax.ParseConfig([]byte(source), "/blah/main.tf", hcl.InitialPos)
	for _, diag := range diagnostics {
		t.Log(diag.Error())
	}
	body := file.Body.(*hclsyntax.Body)
	hclsyntax.VisitAll(body, func(node hclsyntax.Node) hcl.Diagnostics {
		t.Logf("%T", node)
		return nil
	})
	t.FailNow()
}

output:

--- FAIL: TestParse (0.00s)
    /Users/jarred.nicholls/code/vscode-terraform/hcl-hil/main_test.go:22: /blah/main.tf:1,26-2,1: Invalid block definition; A block definition must have block content delimited by "{" and "}", starting on the same line as the block header.
    /Users/jarred.nicholls/code/vscode-terraform/hcl-hil/main_test.go:26: *hclsyntax.Body
    /Users/jarred.nicholls/code/vscode-terraform/hcl-hil/main_test.go:26: hclsyntax.Attributes
    /Users/jarred.nicholls/code/vscode-terraform/hcl-hil/main_test.go:26: *hclsyntax.Attribute
    /Users/jarred.nicholls/code/vscode-terraform/hcl-hil/main_test.go:26: *hclsyntax.TemplateExpr
    /Users/jarred.nicholls/code/vscode-terraform/hcl-hil/main_test.go:26: *hclsyntax.LiteralValueExpr
    /Users/jarred.nicholls/code/vscode-terraform/hcl-hil/main_test.go:26: *hclsyntax.Attribute
    /Users/jarred.nicholls/code/vscode-terraform/hcl-hil/main_test.go:26: *hclsyntax.TemplateExpr
    /Users/jarred.nicholls/code/vscode-terraform/hcl-hil/main_test.go:26: *hclsyntax.LiteralValueExpr
    /Users/jarred.nicholls/code/vscode-terraform/hcl-hil/main_test.go:26: hclsyntax.Blocks
    /Users/jarred.nicholls/code/vscode-terraform/hcl-hil/main_test.go:26: *hclsyntax.Block
    /Users/jarred.nicholls/code/vscode-terraform/hcl-hil/main_test.go:26: *hclsyntax.Body
    /Users/jarred.nicholls/code/vscode-terraform/hcl-hil/main_test.go:26: hclsyntax.Attributes
    /Users/jarred.nicholls/code/vscode-terraform/hcl-hil/main_test.go:26: hclsyntax.Blocks
FAIL

Note that it did not parse the second Block, which would have looked like this:

--- FAIL: TestParse (0.00s)
    /Users/jarred.nicholls/code/vscode-terraform/hcl-hil/main_test.go:26: *hclsyntax.Body
    /Users/jarred.nicholls/code/vscode-terraform/hcl-hil/main_test.go:26: hclsyntax.Attributes
    /Users/jarred.nicholls/code/vscode-terraform/hcl-hil/main_test.go:26: hclsyntax.Blocks
    /Users/jarred.nicholls/code/vscode-terraform/hcl-hil/main_test.go:26: *hclsyntax.Block
    /Users/jarred.nicholls/code/vscode-terraform/hcl-hil/main_test.go:26: *hclsyntax.Body
    /Users/jarred.nicholls/code/vscode-terraform/hcl-hil/main_test.go:26: hclsyntax.Attributes
    /Users/jarred.nicholls/code/vscode-terraform/hcl-hil/main_test.go:26: *hclsyntax.Attribute
    /Users/jarred.nicholls/code/vscode-terraform/hcl-hil/main_test.go:26: *hclsyntax.TemplateExpr
    /Users/jarred.nicholls/code/vscode-terraform/hcl-hil/main_test.go:26: *hclsyntax.LiteralValueExpr
    /Users/jarred.nicholls/code/vscode-terraform/hcl-hil/main_test.go:26: *hclsyntax.Attribute
    /Users/jarred.nicholls/code/vscode-terraform/hcl-hil/main_test.go:26: *hclsyntax.TemplateExpr
    /Users/jarred.nicholls/code/vscode-terraform/hcl-hil/main_test.go:26: *hclsyntax.LiteralValueExpr
    /Users/jarred.nicholls/code/vscode-terraform/hcl-hil/main_test.go:26: hclsyntax.Blocks
    /Users/jarred.nicholls/code/vscode-terraform/hcl-hil/main_test.go:26: *hclsyntax.Block
    /Users/jarred.nicholls/code/vscode-terraform/hcl-hil/main_test.go:26: *hclsyntax.Body
    /Users/jarred.nicholls/code/vscode-terraform/hcl-hil/main_test.go:26: hclsyntax.Attributes
    /Users/jarred.nicholls/code/vscode-terraform/hcl-hil/main_test.go:26: *hclsyntax.Attribute
    /Users/jarred.nicholls/code/vscode-terraform/hcl-hil/main_test.go:26: *hclsyntax.TemplateExpr
    /Users/jarred.nicholls/code/vscode-terraform/hcl-hil/main_test.go:26: *hclsyntax.LiteralValueExpr
    /Users/jarred.nicholls/code/vscode-terraform/hcl-hil/main_test.go:26: *hclsyntax.Attribute
    /Users/jarred.nicholls/code/vscode-terraform/hcl-hil/main_test.go:26: *hclsyntax.TemplateExpr
    /Users/jarred.nicholls/code/vscode-terraform/hcl-hil/main_test.go:26: *hclsyntax.LiteralValueExpr
    /Users/jarred.nicholls/code/vscode-terraform/hcl-hil/main_test.go:26: hclsyntax.Blocks
FAIL

I haven't looked closely at HCL1; are you saying that the ast.File returned from hcl.ParseString would incorporate the entire AST despite a parse error? It sounds like that's what you're saying, and thus how build() is able to go a step further and do parseHilWIthPosition() throughout all Value type 9 nodes...? Or, would it stop short in its AST construction as is seen in HCL2?

@jnicholls

This comment has been minimized.

Copy link

commented May 9, 2019

Thank you for the explanation on the FileIndex parts, and the expectation of Sections vs Properties! In HCL2, we'll have inner Blocks, which will in your definition become Properties instead of their own Sections.

@mauve

This comment has been minimized.

Copy link
Owner

commented May 9, 2019

Feel free to change FileIndex to suite whatever is best given the HCL2 library. Unless we need to keep both around.

HCL1 is not able to recover from any parse errors (to my knowledge), I was kinda hoping that HCL2 would be better at parsing here, maybe your example is just too hard to recover from. That means, to clarify, that hcl.ParseString does not return the AST when parsing fails.

  1. when parsing fails (because there is a HCL syntax error) then hcl1.ParseString() returns nil, err
  2. when parsing succeeds then hcl1.ParseString() returns ast, nil
  3. when parsing succeeds we visit the AST in build() and send type 9 nodes (value-strings) and heredoc (type 10 I think) to hil.ParseStringWithPosition() (or similar name)
    1. because hcl1.ParseString() has succeeded, we have an AST (which means we can build a FileIndex)
    2. so now errors in FileIndex.diagnostics are parse errors returned by hil.ParseString...()

At least hclsyntax.ParseConfig() (HCL2) returns a list of diagnostics which means that it can recover from some errors, if it returns an AST anyway I do not know. I think one of the big changes in HCL1 to HCL2 was that HCL and HIL were merged so that the HCL2 parser now needs to parse HIL aswell.

Thanks for giving it a try.

@jnicholls

This comment has been minimized.

Copy link

commented May 9, 2019

Ok, well it does seem that HCL2 is an improvement, and it does return multiple diagnostics (even though sometimes it'll complain about the same root issue multiple times, which means the parser isn't really "undoing" any state internally after encountering a syntax or grammar error in order to continue forward to the next expression/attr/block/etc. as if nothing bad happened). I don't think it could be used for auto-complete. There are functions for identifying a node by position, but not any to suggest next tokens. It does however have functions, given an execution context, to evaluate expressions...which could be useful.

From hclsyntax.ParseConfig:

// ParseConfig parses the given buffer as a whole HCL config file, returning
// a *hcl.File representing its contents. If HasErrors called on the returned
// diagnostics returns true, the returned body is likely to be incomplete
// and should therefore be used with care.
@juliosueiras

This comment has been minimized.

Copy link

commented May 9, 2019

@mauve Hi, I created a LSP for terraform and maybe it will help with adding more HCL2 support to the extension? (since I did also do a client extension for vscode but is lacking syntax and indentation and etc)

Edit: I will try to add every possible LSP feature in the plugin, the most difficult one is going to be in-scope completion in for each loop

@jnicholls

This comment has been minimized.

Copy link

commented May 9, 2019

@juliosueiras That is great, a language server for Terraform is definitely a needed thing in the community. I'd imagine once it matures more that we'd simply plug into that. Short term I see a fairly clear path for integrating HCL2 into this extension that should only take a couple of hours of development time after it's well-understood how to integrate it without breaking too many interfaces on the first-order pass. I'd rather save a lot of refactoring and cleanup for a second pass. But ultimately yes, having LSP integration makes a lot of sense; if not entirely, as an option at least.

@juliosueiras

This comment has been minimized.

Copy link

commented May 9, 2019

@jnicholls just want to ask, what do you consider the most require feature for the lsp to have? (since I want to get a general ideal of what to target next)

right now the LSP support:

  • Variables complex completion(infinite nesting type)
  • Provider Config completion
  • Resource(with infinite block) completion
  • Data source completion
  • Dynamic Error Checking(Terraform and HCL checks)
  • Communication using provider binary(so it will support any provider as long as is built with terraform 0.12 sdk)
  • Module nesting(inifinte as well) variable completion

I am expecting to the following implemented within this/next week:

  • Interpolation completion(so function inside of a template wrap, inside of list etc
  • More Dynamic Error Checking for RHS attributes
  • Locals(with expanded check)
  • Remote modules
  • Dynamic Block & For Each loop

after the above implemented, then I will be working on other LSP features(symbols, codelens, codeactions, etc)

Any feedback is greatly appreciated

Edit: also the reason I did the LSP is because I created the vim terraform plugin but is mostly regex solution, and with HCL2 allowing very very very nested variable structure, I decided to do a LSP instead for HCL2

@jnicholls

This comment has been minimized.

Copy link

commented May 9, 2019

@juliosueiras You are (and within a week or two, even more so) further than I expected! I think your to-do list is 100% aligned with what I’d suggest, prioritizing error checking and completions. Next I’d say symbols and anything else necessary for good hover and goto support. I’ll admit, I am not 100% familiar with the LSP specification and where the line is drawn between it and the features it powers in editors.

@mauve

This comment has been minimized.

Copy link
Owner

commented May 10, 2019

@juliosueiras @jnicholls I am fine with using an external language-server but then I think it needs to be either automatically downloaded and updated or bundled with the plugin, I used to have an external tool a while back and most users didn't figure out that they needed to install the tool which led to many support-requests.

@juliosueiras

This comment has been minimized.

Copy link

commented May 10, 2019

the lsp is a single binary, so either option work

@juliosueiras

This comment has been minimized.

Copy link

commented May 11, 2019

@jnicholls added Basic Dynamic Block completion https://asciinema.org/a/XhGFudMZ5mNCb6dndGbgc5iSu , right now will try to implement inferred type completion in for each

@juliosueiras

This comment has been minimized.

Copy link

commented May 12, 2019

now there is also for each completion https://asciinema.org/a/245663

@mauve

This comment has been minimized.

Copy link
Owner

commented May 17, 2019

@juliosueiras @jnicholls what is the plan? are you guys working on integrating the language-server?

@juliosueiras

This comment has been minimized.

Copy link

commented May 17, 2019

@mauve I am all for integrating the lsp into this plugin, right now I am mostly focus on making the lsp itself feature complete, so if there is anything that you guys need as high priority then I can do those first instead

@dhdersch

This comment has been minimized.

Copy link

commented May 22, 2019

@juliosueiras I use this extension every day, and I feel like it would greatly benefit from the LSP and HCL2 support (even if it isn't 100% complete yet). Seems like the official Terraform 0.12 release is imminent. Completely up to you what you prioritize of course.

EDIT: 0.12 was released minutes after commenting.

@JustinGrote

This comment has been minimized.

Copy link

commented May 23, 2019

FYI 0.12 just came out so this is going to be pressing...
https://www.hashicorp.com/blog/announcing-terraform-0-12

@mauve

This comment has been minimized.

Copy link
Owner

commented May 23, 2019

I agree that this is a required feature and getting more urgent all the time. Sadly due to a new job and role I have no time at all to focus on this project except reviewing PR and doing releases.

It saddens me to say that I have for a few months now unsuccessfully tried to engage Hashicorp in the project which is why these new features are lagging.

I would love if the community could pull together here and help ship a better autocompletion and 0.12 support based on @juliosuerias language server.

I am very proud that we have a rather large user base (around 70k monthly actives, top 40 in downloads 🎉🎉) and it feels bad that I cannot devote more time.

Therefore I would really love to see this (rather big) change being shipped without my involvement as I fear without it the plugin will end up being rather useless.

Thanks everybody for using my plug-in it makes me proud to have you as users. 🎉

@apparentlymart

This comment has been minimized.

Copy link

commented May 30, 2019

I've been using vscode-terraform to edit 0.12-style Terraform configurations for months now due to it being my primary dev environment and my having to test Terraform 0.12 😉 so I can definitely relate to the frustration of things not working 100% here.

With that said, it seems like others are having a different experience to me, and I'm curious to understand in what way and why. For me, the extension has still been broadly working: syntax highlighting works well enough (doesn't understand the new language constructs, but still works for the old syntax), autocomplete is still working in lots of cases, etc. The main annoyance I saw is that the embedded HCL/HIL parser in the extension of course cannot parse correctly any file using 0.12-only syntax, and so it produces error notations on the first non-interpolated expression in each file, which then means it cannot detect any actual syntax errors in the file.

If that is the behavior others are seeing too, I wonder if a short-term fix here would be to have an option to disable the syntax check that is powered by the embedded HCL/HIL parsers while leaving everything else enabled and working as best it can. There would be no red error indications at all then, which is not ideal either by any means, but perhaps less annoying than the current situation.

Terraform 0.12 also includes terraform validate -json which is intended to allow an extension like this to outsource that sort of checking to the Terraform CLI itself. I don't know the internals of this extension well at all, so I'm not sure what it would take to integrate that, but perhaps it would make a suitable replacement for the embedded HCL/HIL parsers (for error-detection purposes only) to tide over until a more complete solution is available.

(Sadly of course terraform validate -json is not available in Terraforn 0.11, so I guess to use it would require either detecting somehow whether Terraform 0.12 or later is in use or having an option for the user to choose between these two behaviors explicitly. I don't think we currently have a straightforward way to ask Terraform directly what version it is right now -- other than the human-oriented terraform version command -- but we could perhaps add such a thing in a later 0.12.x release if it would be useful.)

@adamdry

This comment has been minimized.

Copy link

commented May 30, 2019

I am having the same experience as you although I haven't used it enough to know exactly what is and isn't working. Tbh, I just disabled the plugin when I got problems that aren't actually problems. Upon realising this meant no syntax highlighting at all I turned it back on and put up with the false negatives.

I wonder if a short-term fix here would be to have an option to disable the syntax check that is powered by the embedded HCL/HIL parsers while leaving everything else enabled and working as best it can.

This sounds like a cracking idea!

@dhdersch

This comment has been minimized.

Copy link

commented May 30, 2019

@adamdry @apparentlymart Until this extension is ready, I have disabled it and created my own private extension that only provides syntax highlighting based on the TextMate grammer from the hcl2 repository.

I just published the extension, and it is available here if anyone wants to try it out.

EDIT: I'll also add that I tried integrating it with terraform-lsp and had some success. However, the LSP isn't quite ready yet as it crashes on many of my existing terraform files that I know for sure are valid.

@adamdry

This comment has been minimized.

Copy link

commented May 30, 2019

Thanks, I'll give it a go!

@astorath

This comment has been minimized.

Copy link
Author

commented May 30, 2019

JetBrains just released HCL2 support (I know it is a community plugin, but AFAIK it's being imported into IntelliJ, more on this here: VladRassokhin/intellij-hcl#155

The plugin itself: https://plugins.jetbrains.com/plugin/7808-hashicorp-terraform--hcl-language-support

Tested it out right now and it's fine by me.

@mauve

This comment has been minimized.

Copy link
Owner

commented May 30, 2019

@apparentlymart it would be relatively easy to integrate the new 0.12 functionality of calling terraform validate -json, the class Runner keeps track of all terraforms it can find via configuration or by looking into $PATH and figures out the version of all terraforms.

@adamdry you can disable the HCL/HIL parsing by disabling the indexing feature (requires restart and not really tested) this will also disable a lot of other features but should at least remove the error markers

@juliosueiras

This comment has been minimized.

Copy link

commented May 30, 2019

@astorath I tested the new intellij-hcl, and so far it look like more of a syntax upgrade 0.12 and basic top-level items(dynamic) instead of full completion/intellisense(for each, dynamic content, nested variables,etc)

@dhdersch sorry for current issues =( , is it ok if you can submit a issue on the repo so I can look into? I will aiming to have most top level features done within 2-3 weeks, and extra features that I have in mind like displaying evaluation of the interpolation, completion of inner remote state resource, etc done after that

@MattFenner

This comment has been minimized.

Copy link
Contributor

commented May 31, 2019

I have never contributed to this project before, but I am keen to help out with this feature if i can. Are there any small grunt-work type jobs i can help with? Or is it one that is going to need people familiar with the whole thing?

@mauve

This comment has been minimized.

Copy link
Owner

commented May 31, 2019

@dhdersch @juliosueiras integrating the language-server at its current state might be preferable to waiting for it to be super-complete, that way we can start collecting metrics and crash logs from many users.

@MattFenner you could have a look at the tmLanguage files if you want to to make them compatible with 0.12 syntax, or integrate the terraform validate -json feature in 0.12, the class Runner keeps track of which terraforms exist and what version they are, that way you can enable or disable the feature based on whether a 0.12 version has been found.

@MattFenner

This comment has been minimized.

Copy link
Contributor

commented May 31, 2019

@mauve I'll try to have a look at the tmLanguage files.

I'm sorry, i'm very new to this contributing to open source thing. If I had something working, what would be the process for submitting the fix, would i do a pull request against this task, or create a separate one?

edit: just submitted a pull request, hopefuly i did it right :p

@mauve mauve changed the title feat: hcl2 support feat: Terraform 0.12 support (was hcl2 support) Jun 12, 2019

@mauve

This comment has been minimized.

Copy link
Owner

commented Jun 13, 2019

the fixes by @MattFenner regarding the syntax highlighting have been merged and released as part of 1.3.12.

@juliosueiras when do you think we can integrate a version of your language-server?

@mauve mauve pinned this issue Jun 13, 2019

@Wenzil

This comment has been minimized.

Copy link

commented Jun 14, 2019

Anyone has been able to disable the indexing? The following user settings.json doesn't work for me:

{
    "terraform.indexing": {
        "enabled": false
    }
}
@wobeng

This comment has been minimized.

Copy link

commented Jun 16, 2019

Any update on this?

@JustinGrote

This comment has been minimized.

Copy link

commented Jun 16, 2019

@Wenzil @mauve The indexing setting isn't taking for me either. Looking at the code it gets passed through an interpolation thingy first, maybe a bug there.

Not being a typescript developer I was able to find the relevant lines in extension.ts and just comment them out, I'll try to build it but need to get docker on this machine.

If I can do that, then at the least I can set up a tasks.json problem matcher to use terraform -validate, and if I can rig it up to a filewatcher then it accomplishes the same goal for now (at least in term of syntax validation)

@btorresgil

This comment has been minimized.

Copy link

commented Jun 16, 2019

I found a way to disable indexing. Added this to my settings.json:

{
  "terraform.indexing": {
    "enabled": false,
    "liveIndexing": false,
    "exclude": ["**/*"]
  },
}

Then restart VSCode. In my experience, the line "exclude": ["**/*"] and restarting VSCode are required.

Now I have syntax highlighting without the false positive syntax errors.

@Skaronator

This comment has been minimized.

Copy link

commented Jun 16, 2019

Thanks, I'll give it a shot!

@chfrodin

This comment has been minimized.

Copy link

commented Jun 17, 2019

It worked for me @btorresgil. Thanks!

@weeco

This comment has been minimized.

Copy link

commented Jun 17, 2019

I understood that the TF 0.12 support is not done yet, but right now the syntax highlighting marks the usage of variables as error: "Unknown token: 5:17 IDENT var.namespace".

e.g.

resource "kubernetes_deployment" "distributor" {
  metadata {
    name      = "cortex-distributor"
    namespace = var.namespace <-- error
  }

Is this just me? (I am using version 1.3.12)

@bostrowski13

This comment has been minimized.

Copy link

commented Jun 17, 2019

@weeco not just you, i have the same issue and I'm on the latest version here.

Presently things like this throw the same error you're seeing.

variable "remote_state_bucket" {
  type        = map
  description = "Remote State Bucket to query for infrastructure configuration based on env"
}
@mauve

This comment has been minimized.

Copy link
Owner

commented Jun 17, 2019

@weeco @bostrowski13 we do not support TF 0.12 yet, to get rid of these errors ensure you have the following config:

{
  "terraform.indexing": {
    "enabled": false,
    "liveIndexing": false,
    "exclude": ["**/*"]
  },
}
@bostrowski13

This comment has been minimized.

Copy link

commented Jun 17, 2019

So does this disable TF linting and syntax for just the sceneario above or does it totally disable it?

@mauve

This comment has been minimized.

Copy link
Owner

commented Jun 17, 2019

most features of the plugin (e.g. CodeLense references, the treeview, goto definition and so on) require the successful parsing of the template files, this parsing only supports HCL1/TF <0.12; this config disables all those features

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.