Question: Does there exist a TOML formatter?

[alok]

I've not found one and I'd like something like the gofmt of TOML, if it exists.

[eksortso]

The short answer is, there isn't one, for some well-founded reasons. If you want a formatter now, you can grab a TOML decoder library that works, then grab a TOML emitter library that will do what you want, and then put them together and tweak them until you've made your ideal formatter, which you can use on all your TOML files. Assuming you want that.

This is where the difference kicks in. For programming code, a formatter makes good sense. Uniformity makes code more readable. You mention gofmt for Go code, and I'm fond of black for Python.

But what does a properly formatted configuration file look like? We don't have a canonical representation for all configuration data, and if we imposed one, the resulting equivalent TOML files could be less friendly to human eyeballs and human editors than the original TOML file. In fact, we may want certain TOML features in one application's configuration (like hex integer formats) that would look out of place in the configurations for other applications (like for astronomical data processing).

We need to ask some other questions first.

• What are the best practices for writing TOML files in general?
• What are the best practices when the TOML is used in a particular context?

Any formatter worth its salt would have detailed answers to both of these questions and would apply its principles mercilessly. And good luck finding a single set of principles that would satisfy everybody.

[Ltrlg]

Your proposed implementation would lose comments which is imho a non-starter.

Programming code formatters usually do not change algorithm representation either: a language may have multiple ways to iterate over a collection, yet formatters will not change one to another (they can be coupled with linters which will emit warnings, but those have different scope). They mostly format a given syntax tree by inserting or removing blank characters. There is definitely a use for this in TOML. For example a consistent indentation style (be it “never indent”, “indent subtables”, “indent in tables” or anything one might come up with) makes reading a file much easier than having mixed style, as it does for programming code.

For best practices, many formatters end with a configuration file because different peoples want different styles. One could start implementing a TOML formatter with mandatory configuration (and being open for new values), then add some default once they get user feedback.

[pradyunsg]

There's https://github.com/jumpscale7/python-pretty-toml. No clue how it is though.

[pradyunsg]

@alok has your question been answered? If so, please feel free to close this issue. :)

[tomwhoiscontrary]

All the problems with formatting that @eksortso mentions apply to formatting code too, and yet, against all odds, code formatters exist. Personally, i just want to know whether i should put spaces inside the braces of inline tables or not.

I tried the Python prettytoml thing, but found that it preserved the whitespace in inline tables!

Oh, well, for now i will maintain artisanal hand-formatted configuration files.

[bd82]

I've created a prettier plugin for TOML.

• https://github.com/bd82/toml-tools/tree/master/packages/prettier-plugin-toml

I've also implemented my own Toml parser in JavaScript to avoid the comment losing issue described above.

• https://github.com/bd82/toml-tools/tree/master/packages/parser

It is still at an early stage and feedback would be highly appreciated 😄