Hacker News Reader

Comment by yawaramin | Hacker News Reader

Looking at the definition from Steve's post:

> For this system to work, you first need to declare a public API. ... Once you identify your public API, you communicate changes to it with specific increments to your version number.

If you don't have a public API in Prettier, SemVer doesn't actually apply. If you do have a public API, only changes to that API (meaning the types, arities, functions, names, modules etc.) qualify for version number bumps. Everything else (like changing the output format) does not qualify.

View on HN

I’m no expert in semver, but I’m fairly confident that updates which change outputs absolutely count as breaking changes. Surely it isn’t just the signatures of public APIs that are considered to be breaking changes.

It seems to me that the semver concept of “breaking changes” by definition applies to almost all changes to a code formatted like Prettier, except for updates which truly don’t affect the output of any given input (like performance improvements or support for additional platforms).

Most pieces of software can have non-breaking changes like adding new features, but if you add a new feature to Prettier (like specific formatting rules for React hooks [0]), you of course change the formatted output of code that uses React hooks.

https://github.com/prettier/prettier/blob/master/CHANGELOG.m...

It's as simple as adding to the README 'do not depend on specific output as it will change between versions' and then you're doing server...

Well, sure, you could always just lie. But in practice, Prettier updates would literally be breaking changes, as in, if you have your CI verifying that code conforms to Prettier's formatting, and you're using a new version of Prettier locally, your commits will literally break the tests. Which is, of course, what "breaking change" means in practice.

Looking at the actual specification ( https://semver.org/ ):

> 1. Software using Semantic Versioning MUST declare a public API. This API could be declared in the code itself or exist strictly in documentation. However it is done, it should be precise and comprehensive.

I don't believe we can make such a claim about Prettier's output format. For example, how would you denote a backward-compatible change to the output format?

Prettier has a clear API.

That’s my point: there by definition cannot be backwards-compatible changes to the output format.

> there by definition cannot be backwards-compatible changes to the output format.

In that case we can conclude that it's incompatible with SemVer! SemVer is all about trying to convey what changes to a package are backward-compatible and thus are safe to upgrade to new versions. The whole point is that you can say something like "that-package": "^3.9.1" and mean that you're OK to upgrade up to anything less than 4.0.0. If you can never do that, the package is obviously not using SemVer.

Reply on news.ycombinator.com