build: Upgrade to TypeScript 4.3 #145
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
SimonAlling
added a commit
that referenced
this pull request
Jul 23, 2024
This will enable upgrading to Jest 26 (#144; see #145). ## Breaking? See #145 for details on why this should possibly be considered a breaking change. I consider it backward compatible, because I don't think any consumer is broken by it. Notably, building with and without this PR in different Git working trees and using `git diff --no-index` to diff the emitted code (`build/` and `lib/`) reveals that the only difference is that some expressions in `.js` files are transformed from `foo` to `(0, foo)`.
SimonAlling
added a commit
that referenced
this pull request
Jul 24, 2024
This will enable upgrading to Jest 29, which [requires] TypeScript 4.5 if `jest-environment-jsdom` is used.
I did this:
npm install --save-dev --save-exact [email protected]
Then I got this warning when running `npm run lint`:
WARNING: You are currently running a version of TypeScript which is not officially supported by @typescript-eslint/typescript-estree.
You may find that it works just fine, or you may not.
SUPPORTED TYPESCRIPT VERSIONS: >=3.3.1 <4.5.0
YOUR TYPESCRIPT VERSION: 4.5.5
Please only submit bug reports when using the officially supported version.
So I did this:
npm install --save-dev @typescript-eslint/eslint-plugin@^4
It didn't help, so I did this:
npm install --save-dev @typescript-eslint/eslint-plugin@^5 @typescript-eslint/parser@^5
## Breaking?
See #145 for details on why this should possibly be considered a breaking change.
I consider it backward compatible, because I don't think any consumer is broken by it. Notably, building with and without this PR in different Git working trees and using `git diff --no-index` to diff the emitted code (`build/` and `lib/`) reveals that it is exactly identical.
[requires]: https://jestjs.io/docs/upgrading-to-jest29#jsdom-upgrade
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I did this:
Then I got this warning when running
npm run lint:So I did this:
Reason
Upgrading TypeScript is always nice, just to get access to a better version of the language. There's also a specific reason: I want to upgrade Jest, and with Jest 26 (#144),
npm run buildfails with TypeScript versions older than 4.4 (which I will upgrade to in an upcoming PR):Breaking?
It's generally tricky to determine whether upgrading to a new major version of TypeScript is breaking for our consumers. (TypeScript doesn't use SemVer; this PR should be thought of as upgrading from v42 to v43.) As soon as we have upgraded, we might accidentally – and without even realizing it – start writing code resulting in
.d.tsfiles with new syntax that older versions can't even parse, etc.So one could argue that to err on the side of caution, we should release a new major version every time we've upgraded our TypeScript version. But I think that might be taking it too far. And what do we even know about our consumers' TypeScript versions in the first place? It quickly spirals out of control. Maybe we should extend the CI setup to include checks with different TypeScript versions?
semver-ts is an attempt at describing the problem of TypeScript + SemVer and formalizing how it should be handled. I've just started reading about it and we're not even close to compliant.
This time, I'll go with considering this a backward compatible change, since I don't believe any consumer is broken by it. This belief is supported by the fact that the emitted code is exactly identical, modulo whitespace. (I figured that out by diffing the output of
cat build/**/*.* lib/**/*.*afternpm run buildwith and without this PR.)