aee8c49b75
This uses the `printer` package to normalise HCL files. It's inspired by github.com/fatih/hclfmt - but it differs in that it's intended to be more generic, re-usable, and follow the semantics of `gofmt` or `go fmt`. I intend to utilise this in Terraform by implementing `terraform fmt` sub-command which will normalise all files in the current working directory (like `go fmt ./..`) or contents over STDIN (with `terraform fmt -` that could be used by editor plugins). So that Terraform users can benefit from linting without installing another package/binary. I hope that by placing most of the logic in the HCL package it should be easy to implement sub-commands in other projects that also use HCL. Some notes about the implementation: - the significant difference from `gofmt` is that STDIN/STDOUT are passed in and errors aren't logged/written directly to STDERR, which gives consumers (e.g. Terraform) the ability to set appropriate exit codes - I chose to use inline fixtures instead of files because there were a number of times where I needed to reference the contents and group them together with diff output - it seemed simplest to construct the expected outputs by looping over the relevant fixtures and building up a string/byte slice, hope it isn't too confusing to read - the test failure reporting is kind of rough because the outputs are so large, but I didn't want to add another diff function - I chose to have a separate test for sub-directories rather than making it the default in the fixtures so that I didn't need to add additional logic to the fixture rendering - the fixtures are sorted by filename before any of the tests runs so that they match the order that they are read from disk by `filepath.Walk()` |
||
|---|---|---|
| hcl | ||
| json | ||
| test-fixtures | ||
| .gitignore | ||
| .travis.yml | ||
| decoder_test.go | ||
| decoder.go | ||
| hcl_test.go | ||
| hcl.go | ||
| lex_test.go | ||
| lex.go | ||
| LICENSE | ||
| Makefile | ||
| parse.go | ||
| README.md | ||
HCL
HCL (HashiCorp Configuration Language) is a configuration language built by HashiCorp. The goal of HCL is to build a structured configuration language that is both human and machine friendly for use with command-line tools, but specifically targeted towards DevOps tools, servers, etc.
HCL is also fully JSON compatible. That is, JSON can be used as completely valid input to a system expecting HCL. This helps makes systems interoperable with other systems.
HCL is heavily inspired by libucl, nginx configuration, and others similar.
Why?
A common question when viewing HCL is to ask the question: why not JSON, YAML, etc.?
Prior to HCL, the tools we built at HashiCorp used a variety of configuration languages from full programming languages such as Ruby to complete data structure languages such as JSON. What we learned is that some people wanted human-friendly configuration languages and some people wanted machine-friendly languages.
JSON fits a nice balance in this, but is fairly verbose and most importantly doesn't support comments. With YAML, we found that beginners had a really hard time determining what the actual structure was, and ended up guessing more than not whether to use a hyphen, colon, etc. in order to represent some configuration key.
Full programming languages such as Ruby enable complex behavior a configuration language shouldn't usually allow, and also forces people to learn some set of Ruby.
Because of this, we decided to create our own configuration language that is JSON-compatible. Our configuration language (HCL) is designed to be written and modified by humans. The API for HCL allows JSON as an input so that it is also machine-friendly (machines can generate JSON instead of trying to generate HCL).
Our goal with HCL is not to alienate other configuration languages. It is instead to provide HCL as a specialized language for our tools, and JSON as the interoperability layer.
Syntax
For a complete grammar, please see the parser itself. A high-level overview of the syntax and grammar is listed here.
-
Single line comments start with
#or// -
Multi-line comments are wrapped in
/*and*/. Nested block comments are not allowed. A multi-line comment (also known as a block comment) terminates at the first*/found. -
Values are assigned with the syntax
key = value(whitespace doesn't matter). The value can be any primitive: a string, number, boolean, object, or list. -
Strings are double-quoted and can contain any UTF-8 characters. Example:
"Hello, World" -
Numbers are assumed to be base 10. If you prefix a number with 0x, it is treated as a hexadecimal. If it is prefixed with 0, it is treated as an octal. Numbers can be in scientific notation: "1e10".
-
Boolean values:
true,false -
Arrays can be made by wrapping it in
[]. Example:["foo", "bar", 42]. Arrays can contain primitives and other arrays, but cannot contain objects. Objects must use the block syntax shown below.
Objects and nested objects are created using the structure shown below:
variable "ami" {
description = "the AMI to use"
}
Thanks
Thanks to: