Automatic formatting of Pkl files

[sin-ack]

Problem Statement

Currently, there doesn't seem to be any way to automatically format a Pkl file. This means that we cannot enforce a standard style when collaborating in a team, nor automatically flag violations in PRs.

Proposed Solution

Something like pkl format, replicating the CLI of Prettier. Examples:

# Take in a file from stdin, and output it as formatted Pkl code to stdout
$ pkl format <<EOF
> foo { bar = 1; baz = 2 }
> EOF
foo {
  bar = 1
  baz = 2
}
# Take a filename, read its contents and output it as formatted Pkl code to stdout
$ echo "foo { bar = 1; baz = 2 }" > foo.pkl
$ pkl format foo.pkl
foo {
  bar = 1
  baz = 2
}
# Take a filename, read its contents and write it as formatted Pkl code to the specified file
$ pkl format foo.pkl --output=formatted.pkl # or -o
$ cat formatted.pkl
foo {
  bar = 1
  baz = 2
}
# Take one or more filenames, and exit with 0 if it is correctly formatted, or 1 otherwise
$ pkl format --check formatted.pkl; echo $?
0
$ pkl format --check foo.pkl; echo $?
Error: foo.pkl is not correctly formatted
1
$ pkl format --check foo.pkl formatted.pkl; echo $?
Error: foo.pkl is not correctly formatted
1
# Take one or more filenames, format them and write to the original files
$ pkl format --write foo.pkl formatted.pkl
Formatted foo.pkl
formatted.pkl was already formatted
$ cat foo.pkl
foo {
  bar = 1
  baz = 2
}

Open Questions

• Should it be configurable? (I'm personally fond of the "nobody's favorite" approach to code formatting lately.)
• When to use multiple lines, and when to use a single line with ; separators?
• Default indentation width? (Suggestion: 2 as used in the documentation)
• Tabs or spaces? (Suggestion: Spaces as used in the documentation)

Relevant Links

Discussion in February: #174

[holzensp]

there doesn't seem to be any way to automatically format a Pkl file

This isn't technically true; pkl-intellij has a formatter. Sadly, that's far too deeply integrated with the IDE SDKs to use in CI and VCS hooks and such.

The current front-end is slightly too deeply integrated with the interpreter. We're working on improving that, so that this kind of tool is easier to build/maintain. It's certainly on our radar.