Consider full Prettier conformance, and the future of this tool

[ryanatkn]

I went out of my way to develop an original fixture set for tsv 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.

Learning from Deno's and Bun's relationship to Node could be instructive. Bun got a lot of mindshare because of its Node compatibility (and performance marketing, but that's a different story). But I don't want to conflate user adoption with optimal tool design, and I'm not convinced the dynamics of JS runtimes apply to code formatters and linters, either. I personally can't wait to never install Prettier again, and tsv is basically there now. ESLint is next. Not to be Bun-like, but the benchmarks tell the story better than I could.

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. I could see it staying in my little niche, and not even try to court users, and I could also see handing off the project to the Svelte team, were they confident that the code is maintainable and not slop, like I am. I have too many projects already and I just want a fast, simple, and unbloated formatter. (and then linter!) 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.

update: after sleeping on it, the value of being zero-config (configless?) so you always get consistent results, no matter what config is hidden where in the context where you run the tool, is what I'm going with. Look at 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.

None of that needs to exist, so with tsv it won't. 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.

[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. Implicit in that statement is the changes LLMs are having on development longer term. I think finding a readable middle ground and simplifying the tooling is a clear long term win for my workflows, no more configs quietly affecting things everywhere you go. Being precious about code formatting is not worth the complexity to me any more.

That's where I think a project like Svelte could use its position to bless one path, and do the work to keep social channels open to re-litigate the things that aren't finalized. Like tabs, for me this is an obvious, "drop it" conversation. Reasonable people will disagree, and they can use another formatter if it bothers them that much.