3 ms·
SemVer for TS in Practice – real world example of avoiding breaking changes
- replygirl 4y agoDoesn't semver already cover this? Just consider types as first-class citizens alongside features and you're good
- chriskrycho 4y agoIn principle, yes, absolutely! You can cover the 90% case with simple rules of thumb, and so just following the top-level recommendations from the spec do indeed cover a lot of it: have tests which cover your type API fully (not just your runtime API), and run those tests against all the versions of TS you support. In practice, it's somewhat more annoying: 1. TypeScript itself ships breaking changes semi-regularly in its own minor releases, so libraries need to do additional work to buffer their consumers from the impact of those (which is what this represented). That, in turn, means library authors need to understand those and have testing in place to account for it. 2. I said "90%" for a reason: the fact that TS has type inference (but not something like Hindley-Milner), a fully structural type system with a bunch of dependent type-adjacent features and control flow analysis for the types means you basically have to model it as higher-kinded mutability, which is… interesting! But complicated. Net: most folks can get a long way by doing some pretty simple things, and the spec outlines that. If you're maintaining a more complicated library and really want to insulate your users from breaking changes outside your own actual major versions, you might have a bit more to do.