Consider full Prettier conformance, and the future of the formatter

[ryanatkn]

TLDR: tsv has non-configurable formatting style behavior; its guide is Prettier+prettier-plugin-svelte+Svelte's config with room for principled+preferred divergences, and adopting all of Svelte's intentional choices

Background you can skip

I took a significantly slower path with tsv by developing an original fixture set instead of using Prettier as an oracle. I suspected this would lead to cleaner architecture, and I documented the process in docs/conformance_prettier.md as I went.

Indeed I found numerous bugs (including a handful of fixes I upstreamed to acorn-typescript), along with quirks that were sometimes heavily downvoted in Prettier's issues. I think the internals would be a lot more tortured had I treated Prettier as an oracle.

But do users care? The costs are sunk -- I probably spent an extra 2-3 months of the initial release's 7 to get this original fixture set and principled divergences -- but if it's not what people expect, then I could backtrack on that decision and go all-in on tracking Prettier and prettier-plugin-svelte.

There's also potential design targets that straddle the line -- keep some principled divergences, and conform where it makes sense given some agreed-upon framing. The conformance doc above can be sliced a few different ways.

A related question is what options of Prettier's to adopt, both data options and config locations, and whether tsv should even have its own configuration scheme.

I don't want to chase user adoption, but I also don't want to contribute to ecosystem fragmentation within the already not-React-sized Svelte world. I like the idea of a zero-config tool that just does what you need, so you don't need to navigate numerous configuration strategies and worry about whether some directory is set up correctly, you just run the tool. This is an attractively simple choice, but my sense is this only works if Svelte has an official tool, if you also want to avoid causing fragmentation.

I built tsv because I wanted faster, slimmer tools where Svelte is first class. Long term I'd expect Svelte to own its language tools. I could see tsv staying in my little niche, and not even try to court users, and I could also see donating the project to the Svelte team, were they confident that the code is maintainable and not slop, like I am. The technical maintenance burden here doesn't worry me at all, the project can be near-automated at this point; it's the social burden and costs that concern me. This leads me to an easy answer: defer subjective questions to Svelte's official repo Prettier config, and point tsv users at that source of truth when it provides an answer.

Update

update: following up on the formatter's config design, the value of being non-configurable so you always get consistent results, no matter what config is included in the context running the tool, is what I'm going with. Here's Prettier's config resolution:

You can configure Prettier via (in order of precedence):

- A "prettier" key in your package.json, or [package.yaml](https://github.com/pnpm/pnpm/pull/1799) file.
- A .prettierrc file written in JSON or YAML.
- A .prettierrc.json, .prettierrc.yml, .prettierrc.yaml, or .prettierrc.json5 file.
- A .prettierrc.js, prettier.config.js, .prettierrc.ts, or prettier.config.ts file that exports an object using export default or module.exports (depends on the [type](https://nodejs.org/api/packages.html#type) value in your package.json).
- A .prettierrc.mjs, prettier.config.mjs, .prettierrc.mts, or prettier.config.mts file that exports an object using export default.
- A .prettierrc.cjs, prettier.config.cjs, .prettierrc.cts, or prettier.config.cts file that exports an object using module.exports.
- A .prettierrc.toml file.

These config strategies imply dependencies on a JS runtime and YAML support, which tsv doesn't have. In keeping with the tool's goal to reduce complexity (and it's currently just Rust, tsv doesn't even need a C compiler let alone one of Node/Deno/Bun), tsv chooses to omit all style config support, both the above and dynamic params when format is called programmatically. I think gofmt, zig fmt, and Python's Black show that a significant fraction of users like monoculture formatting, and swapping out a formatter should be a oneliner for your dev environments and apps. tsv can be useful without its formatter, it was just the first useful tool after that parser that I chose to implement, and it doesn't need to monopolize one's toolset.

I'm also dropping the premium domain -- it'll just be tsv.fuz.dev, under the same domain as my other repos in this org.

The resulting policy from this: follow Svelte's lead and use its Prettier config options, with room for divergences from Prettier's behavior when preferred and defensible.

[pngwn]

I think this makes sense in the abstract but I think this sentence is doing a lot:

I like the idea of a zero-config tool that just does what you need

That's exactly what prettier said. But 'what you need' and what I need are not necessarily the same thing. In theory what you need is consistency but in reality what people want trumps what they need.

Which is why prettier adopted a config. And, to date, I'm not aware of a formatter than doesn't have some kind of config. Even the zero config ones usually cheat and pull in editor config for example.

[ryanatkn]

Thanks, yeah I agree. Given that no formatter can please everybody and they don't have to monopolize users, my preference is to make tsv focused and simple but make sure the formatter is trivially swappable for devs and users. Implicit in my statement is the changes LLMs are having on development longer term. Environment-dependence is a hassle - devs already had to deal with misformatted code being shared on websites and social spaces, and now it's being generated in those places too. My values have shifted from enjoying a personal style to caring more about uniformity with other people's code, including LLM output, lowering the burden of reading through all of the little visual quirks - so I'm shifting my style to the middle and following Prettier's lead with some limited intentional changes, and adopting Svelte's Prettier config options.

[ryanatkn]

re: prior art for non-configurable formatters, see gofmt, zig fmt, and Python's Black (40k+ stars).

My plan is to continue forward with no config options, and copy the Prettier settings used by the official Svelte repos. (the changes from v0.1 to v0.2 are bracketSpacing: true and trailingComma: 'none'). Some people will find the latter surprising so I made a separate discussion for it.

tsv should be swappable with a line of config in your environments, so you can still benefit from other tools in tsv, and ignore the formatter, accepting that it won't be to some people's taste, and go for a reasonable and not-unpopular middle ground. Leaning on Svelte's settings for Prettier+prettier-plugin-svelte gives tsv an easy fallback for any questions/choices - see docs/conformance_prettier.md for the catalog of where tsv differs and why.

tsv's forkability is also something I care about, so people can make their own custom formatters.