feat: HCL output support

[robmorgan]

This extends senc to natively support HCL output files.

TODO

Make sure HCL output files are proper HCL. At the moment I think they are still semi-JSON encoded even though some object keys are surrounded in quotes. Example below.

Current Output

some_attr = {
  "foo" = [
    1,
    2
  ]
  "bar" = true
}
some_block = {
  "some_block_label" = {
    "attr" = "value"
  }
}

Expected Output

some_attr = {
    foo = [1, 2]
    bar = true
}

some_block "some_block_label" {
    attr = "value"
}

[yorinasub17]

A few more chores before this can be merged:

• every commit needs to be signed off (see https://github.com/apps/dco)
• you need at least one commit message following conventional commits so that the automated release process picks it up.

I recommend squashing all the commits when it's ready for merge and adding the sign off + conventional commits message.

I plan on improving both of these points in the future through squash merges, but need some time to configure all the workflows.

[robmorgan]

@yorinasub17 yeah thanks for that. I think I'm going to have to mark this a WIP. Unfortunately until I get the HCL output in an acceptable state, this PR is pretty much going to be useless. I'll keep hacking on it for the time being.

[robmorgan]

Got it! I’ll undo my commit

…

On Sun, 7 Apr 2024 at 11:13 am, Yoriyasu Yano ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ On packages/types/globals.d.ts <#50 (comment)>: OK I updated the release process so this gets published automatically: #58 <#58> You also won't need to bump the package.json version since that will be handled automatically. — Reply to this email directly, view it on GitHub <#50 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABLV65Y6CGGCCGO2TOGCGTY4C2UDAVCNFSM6AAAAABFYSTTLGVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTSOBUHAZTGMJZHE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[robmorgan]

Okay, here's an update.

TLDR: It's nontrivial to add an acceptable HCL implementation to senc.

I need alot more control over how the resulting HCL is generated, which is very hard when serializing POJOs/JSON objects. I had hoped, as per the HCL JSON spec, that a nested JSON block:

"some_block": {
	"some_block_label": {
  	    "attr": "value"
	}
}

Would easily resolve to a TF resource definition (labelled block):

some_block "some_block_label" {
	attr = "value"
}

Unfortunately, HCL2 makes it very hard to do that without using an application-specific schema. The following blog post provides a good write-up. Pay attention to the "JSON Mapping Ambiguity" section. Additionally, this old Terraform GitHub issue explains a few more points.

This leaves me in a bit of a pickle. We would need to extend senc in two different ways:

1. The higher-level layer would be to maintain a well-formed library of types like CDKTF to help with definitions and appropriately serializing resources (example). I guess that could live outside senc and be completely independent.
2. Then the lower level layer would be in the Rust code to combine a Terraform schema somehow if the OutData type is hcl (or we could possibly introduce a tf type). To make matters more complicated, I don't think hcl-rs currently supports schemas so we might have to use the builder pattern to convert some sort of expected JSON format instead.

So in closing:

1. I can either squash and sign commits and we merge this PR as-is;
2. We leave it open now while we discuss different approaches or;
3. We close it.