fatih / hclfmt Goto Github PK

Hey @fatih,

Love the project and all the work you do in general. Was wondering if you'd be open to having hclfmt work on a range?

I have a project with some string literals that contain HCL and they are not formatted nicely (but I want them to be).

Cheers

Is the intent also to do formatting for terraform since it also follows the hcl standard? I have been using https://github.com/mattaitchison/atom-terraform-fmt to get away from discussions over space, newline, and alignment, hoping against hope :). Right now of course in atom editor the .tf files or .tfvars do not get picked up by hclfmt atom plugin.

Thank you!

Maybe this is desired behavior, but currently hclfmt converts this:

### comment line one
### comment line two
provider "aws" {
  foo = "bar"
}

as:

### comment line one

### comment line two
provider "aws" {
  foo = "bar"
}

It correctly (IMO) keeps the second comment directly above the provider object, but otherwise splits the comments.

I know multiline comments can be created with /**/, but the current behavior still seems odd.

I'd like to use hclfmt to ensure my files are correctly formatted before committing changes to my repo. It would be nice if hclfmt would have an option which simply checks if a file has "incorrect" formatting and exits 1 if so (0 if everything is fine). eg hclfmt -q main.tf

Currently I can work around this issue by diffing the output against the source file, but this is a little painful.

    # Priority controls our access to resources and scheduling priority.
    # This can be 1 to 100, inclusively, and defaults to 50.
    # priority = 50

becomes:

  # Priority controls our access to resources and scheduling priority.


  # This can be 1 to 100, inclusively, and defaults to 50.


  # priority = 50

Hi Faith,

Could you please do a build for linux (amd64) and update a release so that we all need not build the binary locally and can refer to the releases? If you can give me permission, I can upload a release too.

-Renjith

Hello! I really like this project and the parser you wrote. It's been helpful for me to understand Go, being only exposed to it through Terraform code base up until now. I have one issue with how you're currently doing the formatting, and I was wondering if this was configurable or not. Here's the issue:

The standard convention when defining terraform variables is to do it similar to this:

# empty variable -- always written on 1 line
variable simple_string_empty { }

# variable with default string parameter -- always written on 1 line
variable simple_string_default { default = "value" }

# example complex variable, written on multiple lines (Maps and Lists)
variable complex_map { 
    default = {
        key1 = "val1"
        key2 = "val2"
    }
}

My question is about the simple variables. When writing a terraform config, it's common to have several, or even 10-20+ of them in a single file. Since these are basically "boiler plate", we want them as terse as possible. The formatter currently outputs these simple variables like this:

# empty variable -- always written on 1 line
variable simple_string_empty {
}

# variable with default string parameter -- always written on 1 line
variable simple_string_default { 
    default = "/dev/sdh" 
}

For empty variables, this increase the LOC in a file 2x, and for simple variables with a default, it increases it by 3x. I spent some time looking at the parser, to see if there were some configurations options that might be set, but didn't have much luck. Is there any way your parser could generically differentiate between simple and complex types, and print them differently?

I don't even necessarily need you to implement this feature if this is not a priority, but if you could confirm that this should be possible, and pick out the relevant section of the codebase, I'd be happy to take a crack at it myself.

TL;DR; -- Love the formatter mostly, but it's blowing up my variable definitions and making it hard to read. Can you fix, or show me where I can fix?

Currently, hclfmt doesn't seem to allow the following formatting:

variable "foobar" {}

Instead, this will be changed to:

variable "foobar" {
}

This seems odd to me and I'm not sure if this is intentional.