Dependency Version Upgrades
Babel
Our published packages only depend on @babel/*
packages as devDependencies.
You can generally upgrade those dependencies with:
yarn add -D @babel/code-frame @babel/core @babel/eslint-parser @babel/parser @babel/types
npx nx run ast-spec:test -u
The fixtures under packages/ast-spec/
describe how the files are parsed under both Babel and our (TSESTree) parser.
ESLint
The typescript-eslint repository contains four kinds of version ranges for the eslint
package:
- Integration tests: Pinned to our lowest supported ESLint version
- Packages with a
*
peerDependency
version: These fall back to the explicitpeerDependency
versions - Packages with explicit
peerDependency
versions: The full range of supported ESLint major versions - Root
package.json
's'devDependency
: A relatively recent release, used only for repository development
Whenever you discover any new areas of work that are blocked by dropping an old ESLint version, such as new ESLint API deprecations, add a TODO comment that will be caught by the regular expressions under Removing Support for an Old ESLint Version.
Adding Support for a New ESLint Version
- Upgrade the root
package.json
devDependency
to the latest ESLint - Add the new major version to the explicit
peerDependency
versions - Check
eslint-visitor-keys
for a new version to be upgraded to as well. - Update Users > Dependency Versions > ESLint
Removing Support for an Old ESLint Version
- Increase the integration tests to the next lowest supported major version (
*.0.0
) - Remove the old major versions from packages with explicit
peerDependency
versions - Search for source code comments (excluding
CHANGELOG.md
files) that mention a now-unsupported version of ESLint.- For example, to remove support for v5, searches might include:
/eslint.*5/i
/todo.*eslint.*5/i
/todo.*eslint/i
- For example, to remove support for v5, searches might include:
- Update Users > Dependency Versions > ESLint
See chore: drop support for ESLint v6 for reference.
Node
The typescript-eslint repository contains three kinds of version ranges for Node:
.github/workflows/ci.yml
'sPRIMARY_NODE_VERSION
: Set to the highest Node version we supportnode-version
: Set to a tuple of our[lowest, highest]
supported versions for our unit tests in CIengines
field in allpackage.json
s: explicitly lists all supported Node ranges
Change those numbers accordingly when adding support for a new Node version or removing support for an old Node version.
See feat: drop support for node v12 + chore: test node v14 on ci.yml for reference.
TypeScript
Adding Support for a New TypeScript Version
We generally start the process of supporting a new TypeScript version just after the first beta release for that version is made available.
Create and pin an issue with a title like TypeScript X.Y Support,
accepting prs
,AST
,dependencies
, andNew TypeScript Version
labels, and the following contents:A link to the TypeScript X.Y Iteration Plan issue from the Microsoft issue tracker
The following text:
This issue is just to track all of the new features and their implementation state in this project.
As with all releases, we will not necessarily support all features until closer to the full release when everything the features are stabilised.
_Please be patient._ ❤️A heading starting with
🔲
for each new TypeScript feature called out in the iteration plan that will impact usA heading titled 🔲
lib.d.ts
Updates and the content We will need to regenerate our types withinscope-manager
A heading titled Other changes with no impact to us containing a list of other changes that we don't believe will impact us
At this stage, it's fine to send and/or review PRs that implement necessary features, but wait to merge them until the new TypeScript version's RC is released
- Whenever a PR is created, add
(#1234)
to its respective heading, and change the heading's emoji from 🔲 to 🏗 - Search for
expectBabelToNotSupport
to see how to support syntaxes not yet supported by Babel
- Whenever a PR is created, add
Once the TypeScript RC version is released, start merging PRs
- Whenever a PR is merged, change the respective heading's emoji from 🏗 to ✅
Create a PR with a title like
feat: update TypeScript to X.Y-rc
and the following changes:- In the root
package.json
, add|| X.Y.1-rc2
to thedevDependency
ontypescript
- Change the
SUPPORTED_TYPESCRIPT_VERSIONS
constant's<
version to the next version of TypeScript - Change the
SUPPORTED_PRERELEASE_RANGES
constant to equal['X.Y.1-rc']
- Rename and update
patches/typescript*
to the new TypeScript version - Run
yarn generate-lib
to updatescope-manager
- In the root
Once all PRs needed for the RC update PR are merged, merge the RC update PR
Once TypeScript releases the stable X.Y version, create and merge a PR with a title like
chore: bump TypeScript from X.YRC to X.Y
and the following changes:- In the root
package.json
, remove|| X.Y.1-rc2
from thedependency
ontypescript
, and bump its<
version to the next version of TypeScript - In the root
package.json
, change thedevDependency
ontypescript
to~X.Y.3
- Rename and update
patches/typescript*
to the new TypeScript version - Any other changes made necessary due to changes in TypeScript between the RC version and stable version
- In the root
Send a PR that updates this documentation page to point to your newer issues and PRs
- Also update any of these steps if you go with a different process
See for reference (caveat: these don't follow the exact process described here):
- TypeScript 4.7 Support
- TypeScript 4.8 Support
- feat: support TypeScript 4.8
- feat: support TypeScript 4.9
- chore: bump TS from 4.9RC to 4.9
Removing Support for an Old TypeScript Version
A single PR can remove support for old TypeScript versions as a breaking change:
- Update the root
package.json
devDependency
- Update the
SUPPORTED_TYPESCRIPT_VERSIONS
constant inwarnAboutTSVersion.ts
- Update the
versions
constant inversion-check.ts
- Update Users > Dependency Versions > TypeScript
- Search for source code comments (excluding
CHANGELOG.md
files) that mention a now-unsupported version of TypeScript.- For example, to remove support for v4.3, searches might include:
4.3
/is.*4.*3/i
/semver.*4.*3/i
/semver.satisfies/
/todo.*ts/i
/todo.*typescript/i
- For example, to remove support for v4.3, searches might include: