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

hcledit always formats the output #64

Open
infraredgirl opened this issue Oct 25, 2022 · 1 comment
Open

hcledit always formats the output #64

infraredgirl opened this issue Oct 25, 2022 · 1 comment

Comments

@infraredgirl
Copy link

Given the following hcl file file.hcl (notice no spaces surrounding the equals sign):

resource "foo" "bar" {
  attr1="val1"
}

hcledit attribute append resource.foo.bar.attr2 '"val2"' -f file.hcl --newline outputs the following (notice spaces were added surrounding the equals sign for attr1):

resource "foo" "bar" {
  attr1 = "val1"

  attr2 = "val2"
}

This is not always a desirable behavior, e.g. when a single small change is done to a large unformatted hcl file, the diff will appear huge, even though most of it is only formatting changes.

Can we have a flag (e.g. --no-format or similar) that makes hcledit not apply formatting? (The user can always opt to apply formatting manually after running hcledit.)

@minamijoyo
Copy link
Owner

@infraredgirl Thank you for your suggestion!

It makes sense that we should not format unchanged parts. However, the hclwrite package we depend on has no way to adjust whitespaces in a specific token. That is to say, if no formatting is applied at all, the output will look like the following:

resource "foo" "bar" {
  attr1="val1"

attr2= "val2"
}

I guess this is not what you expect.

Applying formatting to newly added parts is not as easy as it sounds. I have asked about a related topic in the upstream hcl repository: hashicorp/hcl#316
The answer was to format all the output because a surgical update operation doesn’t have enough context surrounding the change. It is unclear what the correct indentation is, particularly if the input is unformatted.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants