Add useMaxInnerBlocks hook

[colinswinney]

Summary

• New useMaxInnerBlocks hook (TypeScript) that enforces an upper bound on a block's direct innerBlocks. Over-limit additions are removed and a notice is fired.
• Diffs clientIds against a snapshot to remove only the newest extras — existing (potentially filled) children are preserved even when a duplicate lands between them (e.g. [A, A-copy, B] → removes the copy, keeps [A, B]).
• Notice is fully customizable via a noticeOptions passthrough to createNotice — supports custom icon, action buttons, snackbar vs default type, sticky/dismissible behavior, etc. Default icon is info from @wordpress/icons.

API

useMaxInnerBlocks({
    clientId,           // required — parent block's clientId
    max,                // required — number
    message,            // required — notice message
    status = 'warning', // 'warning' | 'info' | 'success' | 'error'
    noticeOptions = {}, // forwarded to createNotice's third argument
});

See hooks/use-max-inner-blocks/readme.md for full usage and customization examples.

Files

• hooks/use-max-inner-blocks/index.tsx — hook implementation
• hooks/use-max-inner-blocks/readme.md — usage and noticeOptions reference
• hooks/index.ts — barrel export
• README.md — added hook link
• example/src/blocks/max-inner-blocks-example/ — TS example block (block.json + edit.tsx + index.tsx) demonstrating every customization path

Test plan

• npm ci && npm run build at the repo root succeeds; dist/index.js exports useMaxInnerBlocks and types are emitted at dist/hooks/use-max-inner-blocks/index.d.ts
• cd example && npm run build && npm run wp-env start boots cleanly (run via root npm ci since the project uses npm workspaces)
• In the editor, insert the Max Inner Blocks Example block and verify:
  • Adding a child past max removes the new child and fires a snackbar
  • Pasting multiple children at once trims to max, fires one notice
  • Duplicating an existing child between siblings removes the duplicate, preserves the originals
  • Inspector toggles work: max (range 1–5), notice type (snackbar/default), icon (default/custom/none), dismissible, explicit dismiss (sticky), action button
  • noticeOptions.icon only renders on snackbar notices (default-type <Notice> ignores it — documented in readme)

CI status

The Cypress, Jest, and build checks fail at the npm ci step with a package.json ↔ package-lock.json mismatch (Missing: stylelint@16.26.1 from lock file plus ~40 transitive deps). This is a pre-existing failure on develop dating to #405 (2026-04-01) — every develop CI run since has hit the same error. Scope-wise it doesn't belong in this PR; tracking separately so the dep tree can be re-resolved with care (a fresh npm install on Node 20 pulled webpackbar forward to a version incompatible with webpack's ProgressPlugin schema).

[github-actions]

🎉 A new testing version of this package has been published to NPM. You can install it with npm install @10up/block-components@testing-406

[colinswinney]

The CI failures here (Jest, Cypress, build, all dying at npm ci) are not specific to this branch — they've been red on every develop run since #405 on 2026-04-01 due to package.json ↔ package-lock.json drift.

Tracking the fix in #407, which only updates the lockfile (no package.json changes). Once that lands on develop and is merged into this branch, the checks should go green.

[colinswinney]

Update on the lockfile fix in #407:

The regenerated lockfile is correctly fixing the npm ci mismatch — Jest and ESLint now go green on #407 (and will also go green here once #407 merges and we sync). The remaining red checks (Cypress, build, release_testing) are separate pre-existing develop infra issues that the now-working install pipeline just exposes — they have nothing to do with the lockfile and will need their own PRs:

• Cypress: workspace-build ordering bug (broken on develop since at least 2026-02-20)
• build (compressed-size): comparison action runs against the base branch, so it can't pass until fix: restore CI on develop (lockfile drift + workflow regressions) #407 lands on develop
• release_testing: npm install -g npm@latest dirties the lockfile before the npm version step

So the fix here unblocks the install step that was blocking every check. The remaining failures can be triaged separately and don't affect this PR's reviewability.

[colinswinney]

Update on #407: confirmed green now (Jest, ESLint, Cypress with all 35 tests, release_testing, Analyze, CodeQL all passing). Once it merges to develop, this PR's checks will go green automatically (the lockfile fix gets merged in, and the only red check on #407 — compressed-size — is a base-vs-head comparison that fails because develop's lockfile is still broken; that resolves itself the moment #407 lands).