Skip to content

Conversation

@JamieB-gu
Copy link
Contributor

@JamieB-gu JamieB-gu commented Oct 23, 2025

This involved some dependency updates, including updating typescript-eslint from v7 to v8, which came with a number of breaking changes1.

Note: Currently based on #14748 until that's merged. The AR validation check should be fixed by that change.

ESLint Config

The first set of changes required to handle this were to our ESLint config.

no-var-requires

no-var-requires has been deprecated in favour of no-require-imports2, and the former has been replaced by the latter in the recommended preset3, which guardian/eslint-config-typescript extends. However, we had the former turned off, so this updates our config to turn the latter off instead.

ban-types

ban-types has been removed and replaced with no-restricted-types, no-empty-object-type, no-unsafe-function-type and no-wrapper-object-types4. Previously we used extendDefaults to include the latter three rules. That option no longer exists, but they're included in the recommended-type-checked preset3, which guardian/eslint-config-typescript extends, so they should still be present in our config. The remainder of our ban-types config involved banning a list of configurable types, which is now handled by no-restricted-types.

Source Files

The second set of changes are to our source files, to fix issues surfaced by the rule changes. These have pre-emptively been handled in earlier PRs, and amount to following these rules:

Footnotes

  1. https://typescript-eslint.io/blog/announcing-typescript-eslint-v8/

  2. https://typescript-eslint.io/blog/announcing-typescript-eslint-v8/#rule-breaking-changes

  3. https://typescript-eslint.io/blog/announcing-typescript-eslint-v8/#updated-configuration-rules 2

  4. https://typescript-eslint.io/blog/announcing-typescript-eslint-v8/#replacement-of-ban-types

@JamieB-gu JamieB-gu added this to the Health milestone Oct 23, 2025
@JamieB-gu JamieB-gu self-assigned this Oct 23, 2025
@JamieB-gu JamieB-gu requested a review from a team as a code owner October 23, 2025 14:48
@JamieB-gu JamieB-gu added the maintenance Departmental tracking: maintenance work, not a fix or a feature label Oct 23, 2025
@github-actions
Copy link

Hello 👋! When you're ready to run Chromatic, please apply the run_chromatic label to this PR.

You will need to reapply the label each time you want to run Chromatic.

Click here to see the Chromatic project.

This involved some dependency updates, including updating
`typescript-eslint` from v7 to v8, which came with a number of breaking
changes, detailed here:

https://typescript-eslint.io/blog/announcing-typescript-eslint-v8/

The first set of changes required to handle this were to our ESLint
config.

`no-var-requires` has been deprecated in favour of `no-require-imports`,
and the former has been replaced by the latter in the `recommended`
preset, which `guardian/eslint-config-typescript` extends. However, we
had the former turned off, so this updates our config to turn the latter
off instead. See:

- https://typescript-eslint.io/blog/announcing-typescript-eslint-v8/#rule-breaking-changes
- https://typescript-eslint.io/blog/announcing-typescript-eslint-v8/#updated-configuration-rules

`ban-types` has been removed and replaced with `no-restricted-types`,
`no-empty-object-type`, `no-unsafe-function-type` and
`no-wrapper-object-types`. Previously we used `extendDefaults` to
include the latter three rules. That option no longer exists, but
they're included in the `recommended-type-checked` preset, which
`guardian/eslint-config-typescript` extends, so they should still be
present in our config. The remainder of our `ban-types` config involved
banning a list of configurable types, which is now handled by
`no-restricted-types`. See:

- https://typescript-eslint.io/blog/announcing-typescript-eslint-v8/#replacement-of-ban-types
- https://typescript-eslint.io/blog/announcing-typescript-eslint-v8/#updated-configuration-rules

The second set of changes are to our source files, to fix issues
surfaced by the rule changes. These have pre-emptively been handled in
earlier commits, and amount to following these rules:

- `no-unused-expressions`
- `prefer-promise-reject-errors`
- `no-empty-object-type`
- `no-unsafe-function-type`

There is one exception to this, where `prefer-promise-reject-errors` has
been disabled for a particular issue in AR.
@JamieB-gu JamieB-gu force-pushed the guardian-eslint-config-typescript-v12 branch from 9ae1271 to 2f084a3 Compare October 23, 2025 15:12
@JamieB-gu JamieB-gu changed the base branch from main to no-unused-expressions-ar October 23, 2025 15:13
@github-actions
Copy link

github-actions bot commented Oct 23, 2025

@JamieB-gu JamieB-gu marked this pull request as ready for review October 23, 2025 15:16
@github-actions
Copy link

github-actions bot commented Oct 23, 2025

Base automatically changed from no-unused-expressions-ar to main October 27, 2025 15:15
@JamieB-gu JamieB-gu added the run_chromatic Runs chromatic when label is applied label Oct 28, 2025
@github-actions github-actions bot removed the run_chromatic Runs chromatic when label is applied label Oct 28, 2025
@JamieB-gu JamieB-gu added the run_chromatic Runs chromatic when label is applied label Oct 28, 2025
@github-actions github-actions bot removed the run_chromatic Runs chromatic when label is applied label Oct 28, 2025
@JamieB-gu JamieB-gu merged commit 69758a8 into main Oct 28, 2025
32 checks passed
@JamieB-gu JamieB-gu deleted the guardian-eslint-config-typescript-v12 branch October 28, 2025 16:12
@gu-prout
Copy link

gu-prout bot commented Oct 28, 2025

Seen on PROD (merged by @JamieB-gu 8 minutes and 40 seconds ago) Please check your changes!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

apps-rendering dotcom-rendering maintenance Departmental tracking: maintenance work, not a fix or a feature Seen-on-PROD

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants