Current use of semver not applicable to prettier

First off, thanks for a great library and fantastic effort for the community.

This is a suggestion about the versioning scheme used by prettier.

I would argue that using the minor version of semver for changes isn’t applicable to prettier. Why? Any changes that leads to different formatting isn’t really compatible with the previous version. For instance, if package.json specifies ^1.2.2 (where a caret version is the default when installing with npm), one repo user could still be at 1.2.2 and another repo user could be at 1.4.4, and they would have different formatting applied the sources leading to an inconsistent style across the project (and following commit wars until the version difference is resolved).

A workaround would be to use a tilde (~) version in package.json to only allow automatic patch upgrades, but since this is not the default behaviour of npm it will probably lead to problems for many people who are not aware of the issue.

My suggestion is to always increment the major version whenever a change that leads to different formatting is applied.

[lydell]

In a way, the API of Prettier is “string in, string out” without saying much about what those strings look like. So in theory we can do any changes we like and release them as patch releases as long as the string -> string contract is preserved. But of course we don’t do that since it wouldn’t be very nice to users 😃

What is the semver change when previously formatted code is formatted differently?

Any. Depends on the case. The more impact, the more bump. Technically, you could say that any change whatsoever is a breaking change. But only doing major releases won’t help anyone. And it would mask actual API breaking changes. This is also why it can make sense to think of the API more of like string -> string where the strings are black boxes like I mentioned above.

What is the semver change when previously rejected code is now formatted?

Most likely minor. (New feature.)

What is the semver change when previously formatted code is now rejected?

This is a tough one. We have this problem for decorators (#2630). There was a similar situation with GraphQL (#4012), where we ended up parsing both old and new syntax but only outputting the new.

For example, if a bug were discovered in the parser that allowed it to be too permissive.

That could likely be a patch release.

---

In summary, the above is how I have understood how things work so far. Basically, Prettier is a hard thing to version. Which is why we recommend pinning the version in package.json. We try to use our best judgement to make the experience smooth for the majority of people.

[azz]

Because almost every PR changes the formatting slightly, which means every release would be major, no minors or patches.

I don’t think it makes sense to bump major for formatting changes. The API is that prettier.format(string) returns a string. If that contract changes, that would be a breaking change, and it would make sense on that occasion to bump the major version.

If Prettier was to overhaul the CLI, remove an option, or change the API itself, those would all be breaking changes.