You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This came up in NixOS/nixfmt#378: what should a formatter do if it sees an invalid file but wants to format it anyway? For example, tree-sitter has this concept of being "robust": that is, it will produce an AST with error nodes if possible. One can imagine formatters that behave similarly: they could still format syntactically invalid input.
IIUC, this is already possible: a formatter that sees a syntactically invalid file can just update the file on disk and print errors to stderr and exit nonzero. I believe this is spec compliant behavior, although it would probably be nice to call it out explicitly in the spec.
However, I believe treefmt --stdin would behave differently: we'd see the formatter exit nonzero and conclude that the file cannot be formatted. You could imagine that we'd instead print the formatted file to stdout, but still print errors to stderr and exit nonzero. Surrounding tooling could then decide how to handle that (either ignore it entirely, or accept the best-effort formatting). This also has implications if we ever add a stdin spec: #586
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
This came up in NixOS/nixfmt#378: what should a formatter do if it sees an invalid file but wants to format it anyway? For example, tree-sitter has this concept of being "robust": that is, it will produce an AST with error nodes if possible. One can imagine formatters that behave similarly: they could still format syntactically invalid input.
IIUC, this is already possible: a formatter that sees a syntactically invalid file can just update the file on disk and print errors to stderr and exit nonzero. I believe this is spec compliant behavior, although it would probably be nice to call it out explicitly in the spec.
However, I believe
treefmt --stdinwould behave differently: we'd see the formatter exit nonzero and conclude that the file cannot be formatted. You could imagine that we'd instead print the formatted file to stdout, but still print errors to stderr and exit nonzero. Surrounding tooling could then decide how to handle that (either ignore it entirely, or accept the best-effort formatting). This also has implications if we ever add a stdin spec: #586Beta Was this translation helpful? Give feedback.
All reactions