An expression becomes a string
JSON has no expression type, so a bare reference has to be wrapped and is then indistinguishable from literal text
resource "aws_s3_bucket" "logs" {
bucket = var.bucket_name
} Convert Terraform HCL to the equivalent .tf.json syntax. Terraform reads both, and the conversion is lossy in one specific way that the output names rather than hides.
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Convert. Nothing leaves this tab.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
JSON has no expression type, so a bare reference has to be wrapped and is then indistinguishable from literal text
resource "aws_s3_bucket" "logs" {
bucket = var.bucket_name
}With no expressions the conversion is lossless, which is the case JSON syntax is good for
resource "aws_s3_bucket" "logs" {
bucket = "my-logs"
versioning = true
}These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Every expression becomes a string, so the file gets harder to read and no easier to edit correctly. The information about which strings are expressions is gone.
Instead:Keep HCL for anything a human maintains. Use JSON syntax only for files a program generates from scratch.
Terraform picks the parser from the extension, so JSON in a .tf file is a syntax error rather than an alternative syntax.
Instead:Name it .tf.json.
HCL to JSON and back cannot recover which strings were expressions, so a bare reference and a literal string containing the same text collapse into one representation.
Instead:Treat the conversion as one-way. Keep the HCL as the source of truth.
Terraform parses HCL and JSON into the same structure. Going from HCL to JSON loses information that cannot be recovered coming back.
Every value in JSON is a string, a number, a boolean, a list or an object. An HCL expression like var.name is none of those, so in JSON syntax it has to be written as a string and Terraform evaluates any string for interpolation. That means "${var.name}" and a literal string containing that text are indistinguishable in the document, and a round trip back to HCL cannot tell you which was meant.
JSON syntax goes in a file ending .tf.json, not .tf. Terraform decides which parser to use from the extension alone, so JSON in a .tf file is a syntax error and HCL in a .tf.json file is one too. Both may be used in the same module.
A heredoc is HCL syntax. The same value in JSON is one string with escaped newlines, which is correct and unreadable. An indented heredoc using the dash or tilde form also had its indentation stripped during parsing, and that stripping is not reversible, so a policy document or a user_data script is worth checking by hand after conversion.
Two resource blocks of the same type and name are an error, but two provider blocks or two ingress blocks are not. In JSON those become an array under the same key, which is the correct representation and looks nothing like the HCL that produced it.
For files a program writes. A generator emitting JSON does not have to get HCL quoting right, and the result is machine-parseable without an HCL library. For files a human maintains, HCL is better in every respect, which is why the expression caveat above matters more than it sounds.
Whether the converted configuration behaves identically, because that depends on how Terraform evaluates the expressions it now sees as strings. It converts the structure, in your browser, and runs nothing. Validate the output with terraform validate before relying on it.