Update dependency @cloudfour/eslint-config to v28

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
@cloudfour/eslint-config	26.1.0 → 28.0.0

---

Release Notes

cloudfour/eslint-config (@​cloudfour/eslint-config)

v28.0.0

Compare Source

Major Changes

• @typescript-eslint/no-floating-promises and
  @typescript-eslint/restrict-template-expressions are now on. Both had been
  off since 2020, when our TypeScript rules were first added. eslint-config-xo
  enables both, so this change deletes our two overrides rather than configuring
  anything: the rules arrive with xo's options, not the plugin defaults.

  Measured across 296 TypeScript files in three consumers — c4-sw-ac-patterns
  (221), linkedin-talent-connect (66) and lighthouse-parade (9) — this is
  nine no-floating-promises reports and two
  restrict-template-expressions. Neither rule is auto-fixable, though
  no-floating-promises offers editor suggestions, so anything either one
  catches has to be edited by hand. That is what makes this a major release.

  no-floating-promises reports a promise that is started and then abandoned —
  no await, no .catch(), no void. It runs with xo's ignoreVoid, so
  void doThing() marks one as deliberately unawaited, and xo relaxes no-void
  to permit that form. The old reasoning for turning it off — that humans should
  decide when to handle a rejection — is what void expresses; the difference is
  that the decision is now visible at the call site instead of indistinguishable
  from an oversight. Six of the nine reports in the sample were un-awaited
  waitFor() calls in test files, where the assertion inside could not fail the
  test.

  restrict-template-expressions runs with xo's allowNumber: true and leaves
  allowAny at its default, so interpolating an any into a template literal is
  still allowed — the specific allowance our override was written for survives
  the rule being on. What it reports is values with no useful string form. Both
  reports in the sample were never, from setters whose type guard narrows the
  guard's own failure branch.

  The @typescript-eslint/no-unsafe-* family stays off, and so does
  no-unsafe-type-assertion, which is a much larger migration (377 reports in
  the same sample) and a separate question.

• func-names is now on, at xo's setting of never. It reports a named
  function expression — const handler = function onClick() {} — and wants
  the name dropped, because since ES6 the variable name is inferred anyway. It
  has nothing to say about function declarations.

  We had turned it off in the original 2018 config with no reason recorded
  anywhere, so this adopts xo's position rather than reversing a decision of
  ours. Zero reports across 434 files in three consumers — modern code reaches
  for arrow functions, which the rule does not touch.

  The case it does cost you is naming a callback purely for debugging, such as
  setTimeout(function tick() {}, 100). Inference does not apply to a function
  passed straight as an argument, so that name is the only thing that shows up
  in a stack trace or profiler. If you want it, // eslint-disable-next-line func-names on that call is the escape hatch.

• capitalized-comments now extends xo's ignore pattern instead of replacing
  it. The pattern exists so autofix does not capitalise commented-out code,
  which then has to be un-capitalised when you uncomment it. Ours was forked
  from xo's years ago and had drifted: we were missing the starts xo added since
  (if (, for (, while (, switch (, class , import , export ,
  type-coverage:), and xo was missing three of ours (return, await,
  console). Both sets now apply, and anything xo adds later arrives on its own.

  Almost entirely a widening, but not purely: xo matches const with a
  trailing space where our old pattern matched a bare const, so a prose comment
  that merely starts with those letters — // constant — is now reported where
  it was not. One such report across 434 files.

Minor Changes

• @typescript-eslint/strict-boolean-expressions is now off. It arrived in
  v26.0.0 with the move to eslint-config-xo, which enables it with
  allowString and allowNumber tightened to false. It was the single largest
  source of TypeScript-only reports in the config, and measurement did not
  justify the cost: 165 reports across 294 TypeScript files in three
  consumers, with no genuine defect in a 34-report sample spanning every
  category the rule distinguishes. What it flagged was optional string
  attributes, || '' defaults and guard clauses — cases where '', 0 and
  absent legitimately mean the same thing.

  Loosening it rather than removing it does not work, which is worth recording
  because it is the obvious first idea. Setting allowString/allowNumber back
  to the plugin defaults clears only 21% of the reports, because three quarters
  of the remainder is string | undefined in a condition — rejected by xo and by
  the rule's own defaults alike. Allowing enough to clear that leaves eight
  reports, and none of those is a defect either.

  Upstream has declined to loosen the rule
  (xojs/eslint-config-xo#108),
  so this is ours to set rather than something to wait on. Projects that want it
  can turn it back on in their own config.

  No project gains a report. Anyone who has already rewritten conditions to
  satisfy it keeps working code; the rule simply stops asking.

• Twenty entries that restated a value eslint-config-xo already sets have
  been removed. No rule changes severity or options as a result — every one was
  verified to resolve identically with and without our line, and the rule
  inventory is unchanged across the removal.

  What it changes is the future. A rule we no longer name is one we would follow
  xo on if it changed its position, rather than silently pinning the old value.
  That is deliberate: restating a value is a standing commitment to track every
  option that rule later grows, and two of our entries had already drifted out of
  step that way without anyone noticing.

v27.1.0

Compare Source

Minor Changes

• @typescript-eslint/no-restricted-types is now scoped to TypeScript files.
  We had it configured in the layer that covers every code file, which quietly
  made the @typescript-eslint plugin mandatory for linting anything at all. A
  project with no TypeScript installed did not skip the rule, it failed outright:

  A configuration object specifies rule "@typescript-eslint/no-restricted-types",
  but could not find plugin "@typescript-eslint".
  

  No project gains or loses a report. The rule only ever matches type
  annotations, so it could not fire on JavaScript in the first place — measured
  against a real consumer project it changed nothing across 66 TypeScript files
  and 120 single-file components, and the rule inventory records exactly one
  difference, on the JavaScript probe. What changes is that a JavaScript-only
  project can now lint with typescript absent from node_modules.

  Note that npm may install TypeScript anyway. eslint-config-xo depends on
  typescript-eslint, which declares a required typescript peer, so a
  project with no TypeScript still gets roughly 31 MB of it. Nothing in this
  config can prevent that; it needs a fix upstream, which we have reported as
  xojs/eslint-config-xo#126.

v27.0.0

Compare Source

Major Changes

• Update eslint-config-xo to v2, which moves eslint-plugin-unicorn from
  v73 to v74. The bump adds, removes and reconfigures no unicorn rule — v74's
  changes are fixes to rules we already run. Measured against a real consumer
  project, it produced three fewer reports across 64 TypeScript files, where
  unicorn/prefer-number-coercion and unicorn/prefer-string-replace-all had
  been flagging cases they misread.

• n/prefer-process-get-builtin-module is now on, added by xo v2. It reports
  require('node:fs') and await import('node:fs') for built-in modules and
  wants process.getBuiltinModule('node:fs') instead. It is not auto-fixable,
  so whatever it catches has to be edited by hand. This is the only rule the
  upgrade turns on, and the only source of new errors in it.

  Most projects will never see it. The rule switches itself off unless the
  nearest package.json declares an engines.node falling entirely within
  ^20.16.0 || >=22.3.0 — the versions where process.getBuiltinModule is
  guaranteed to exist. A package with no engines.node at all, or one as loose
  as >=20, is left alone.

  Where it does apply, the payoff is in ES modules, where it removes the need
  for createRequire. It fires in CommonJS too, where require is the native
  idiom and the rewrite buys nothing, so build scripts and .cjs files are the
  likeliest place to meet it. Turn it off for those paths in your own config if
  it is noisy:

  {
  	files: ['**/*.cjs'],
  	rules: { 'n/prefer-process-get-builtin-module': 'off' },
  }

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[changeset-bot]

⚠️ No Changeset found

Latest commit: b4117e5

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[netlify]

✅ Deploy Preview for cloudfour-patterns ready!

Name	Link
🔨 Latest commit	b4117e5
🔍 Latest deploy log	https://app.netlify.com/projects/cloudfour-patterns/deploys/6ab080460be3c80008dc0a33
😎 Deploy Preview	https://deploy-preview-2499--cloudfour-patterns.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.