Bump skuba from 7.5.1 to 8.0.0

[dependabot]

Bumps skuba from 7.5.1 to 8.0.0.

Release notes

Sourced from skuba's releases.

[email protected]

This version of skuba looks more scary than it is. The major change is that our dependencies have bumped their minimum Node.js requirement from 18.12 to 18.18. Most SEEK projects do not pin minor Node.js versions and are unlikely to be affected by this change.

In the spirit of upgrades, we recently refreshed our ARM64 migration guide and also have one for pnpm. A previous release landed a skuba migrate command to simplify upgrades to Node.js 20 (active LTS) before Node.js 18 reaches EOL in April 2025.

Major Changes

• deps: eslint-config-seek 13 + eslint-config-skuba 4 + typescript-eslint ^7.2.0 (#1487)

  These major upgrades bump our minimum requirement from Node.js 18.12 to 18.18.

  See the typescript-eslint v7 announcement for more information, and consider upgrading your project to the active LTS release with skuba migrate before Node.js 18 reaches EOL in April 2025.

Minor Changes

• deps: semantic-release 22 (#1492)

• deps: TypeScript 5.4 (#1491)

  This major release includes breaking changes. See the TypeScript 5.4 announcement for more information.

Patch Changes

• template: Remove BUILDPLATFORM from Dockerfiles (#1350)

  Previously, the built-in templates made use of BUILDPLATFORM and a fallback value:

  FROM --platform=${BUILDPLATFORM:-arm64} gcr.io/distroless/nodejs20-debian11

  1. Choose the platform of the host machine running the Docker build. An AWS Graviton Buildkite agent or Apple Silicon laptop will build under arm64, while an Intel laptop will build under amd64.
  2. Fall back to arm64 if the build platform is not available. This maintains compatibility with toolchains like Gantry that lack support for the BUILDPLATFORM argument.

  This approach allowed you to quickly build images and run containers in a local environment without emulation. For example, you could docker build an arm64 image on an Apple Silicon laptop for local troubleshooting, while your CI/CD solution employed amd64 hardware across its build and runtime environments. The catch is that your local arm64 image may exhibit different behaviour, and is unsuitable for use in your amd64 runtime environment without cross-compilation.

  The built-in templates now hardcode --platform as we have largely converged on arm64 across local, build and runtime environments:

  FROM --platform=arm64 gcr.io/distroless/nodejs20-debian11

  This approach is more explicit and predictable, reducing surprises when working across different environments and toolchains. Building an image on a different platform will be slower and rely on emulation.

• Jest.mergePreset: Fudge Node16 and NodeNext module resolutions (#1481)

  This works around a ts-jest issue where test cases fail to run if your moduleResolution is set to a modern mode:

  {

... (truncated)

Changelog

Sourced from skuba's changelog.

8.0.0

This version of skuba looks more scary than it is. The major change is that our dependencies have bumped their minimum Node.js requirement from 18.12 to 18.18. Most SEEK projects do not pin minor Node.js versions and are unlikely to be affected by this change.

In the spirit of upgrades, we recently refreshed our ARM64 migration guide and also have one for pnpm. A previous release landed a skuba migrate command to simplify upgrades to Node.js 20 (active LTS) before Node.js 18 reaches EOL in April 2025.

Major Changes

• deps: eslint-config-seek 13 + eslint-config-skuba 4 + typescript-eslint ^7.2.0 (#1487)

  These major upgrades bump our minimum requirement from Node.js 18.12 to 18.18.

  See the typescript-eslint v7 announcement for more information, and consider upgrading your project to the active LTS release with skuba migrate before Node.js 18 reaches EOL in April 2025.

Minor Changes

• deps: semantic-release 22 (#1492)

• deps: TypeScript 5.4 (#1491)

  This major release includes breaking changes. See the TypeScript 5.4 announcement for more information.

Patch Changes

• template: Remove BUILDPLATFORM from Dockerfiles (#1350)

  Previously, the built-in templates made use of BUILDPLATFORM and a fallback value:

  FROM --platform=${BUILDPLATFORM:-arm64} gcr.io/distroless/nodejs20-debian11

  1. Choose the platform of the host machine running the Docker build. An AWS Graviton Buildkite agent or Apple Silicon laptop will build under arm64, while an Intel laptop will build under amd64.
  2. Fall back to arm64 if the build platform is not available. This maintains compatibility with toolchains like Gantry that lack support for the BUILDPLATFORM argument.

  This approach allowed you to quickly build images and run containers in a local environment without emulation. For example, you could docker build an arm64 image on an Apple Silicon laptop for local troubleshooting, while your CI/CD solution employed amd64 hardware across its build and runtime environments. The catch is that your local arm64 image may exhibit different behaviour, and is unsuitable for use in your amd64 runtime environment without cross-compilation.

  The built-in templates now hardcode --platform as we have largely converged on arm64 across local, build and runtime environments:

  FROM --platform=arm64 gcr.io/distroless/nodejs20-debian11

  This approach is more explicit and predictable, reducing surprises when working across different environments and toolchains. Building an image on a different platform will be slower and rely on emulation.

• Jest.mergePreset: Fudge Node16 and NodeNext module resolutions (#1481)

  This works around a ts-jest issue where test cases fail to run if your moduleResolution is set to a modern mode:

... (truncated)

Commits

• 4049ce9 Version Packages (#1479)
• 840c114 Update slack channels (#1496)
• 3091495 Add release preamble (#1495)
• 3bc9ad1 Remove account-level tags (#1494)
• 34a9a36 Bump semantic release (#1492)
• 147659c Fix Unhappy Changelog (#1490)
• 6f5e007 Add forgotten changeset (#1491)
• 3a9c02e deps: typescript ~5.4.0 (#1471)
• 5c6a013 Bump Eslint Config Seek (#1487)
• ec2bbe1 template: pnpm 8.15.5 (#1486)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)