Josh Sherman
While I’m a pretty big fan of TypeScript, there’s some stuff that drives me up a wall. One of those things recently came to light during the release of TypeScript 4.4 on a Friday afternoon.
So it was nearing both end of day and end of week, and we were trying to get one final deployment (of a bug fix) out the door before calling it a week.
The code built just fine and the pull request was reviewed and subsequently merged in.
Upon merging the code it, we run an additional set of tests and build before deploying to production.
And wouldn’t you know it, said tests failed.
After quite a bit of head scratching, it came to light that TypeScript 4.4.2 had recently been released, and rolling back to TypeScript 4.3.5 fixed the issue.
The issue was a change in TypeScript that began to error on a single line of code in one of our shared repositories at work.
To back things up a bit, up until that experience, we had been pinning
TypeScript as such: ^4.3.5, which pins the dependency in such a way that
allows for minor updates to come through. 4.4, 4.5, et cetera.
This was sufficient, because if the maintainers are doing their job, the minor
releases should not contain any breaking changes. Those should be reserved for
major releases, like 5.x, 6.x, et cetera.
Evidently Microsoft didn’t care for this, and opted to drop breaking changes in minor versions of TypeScript. While it was a trivial thing to fix, given the circumstances of having shit break while trying to deploy code that had already passed previous tests, it sucked pretty freakin’ hard.
Having learned a valuable lesson from this experience, we are not pinning
TypeScript to the patch level, but using a value like 4.3.x and 4.4.x so
that we can 100% guarantee that we’re only installing patch releases.
Hopefully this will be sufficient enough, as I’m not very keen on hard pinning a specific major, minor, patch of a dependency.
