Tools: Ban classnames via Syncpack#79061
Conversation
Gutenberg standardised on `clsx` in 2024 ([#61138]) and removed every `classnames` declaration across the monorepo. There is currently no guardrail preventing it from being re-added later — an `npm install classnames` in any workspace would land silently. Add a `Banned` version group to `syncpack.config.mjs` that fails `lint:deps` (and CI) on any declaration of `classnames` in any package.json. The rule is preventive: no current declarations are affected. Picked up as the follow-up suggested in #77950's review. [#61138]: #61138
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
There was a problem hiding this comment.
Pull request overview
Adds a Syncpack guardrail to prevent classnames from being reintroduced anywhere in the monorepo via package.json declarations, complementing existing ESLint import restrictions and avoiding duplicate bundle weight alongside clsx.
Changes:
- Add a new
versionGroupsentry insyncpack.config.mjsmarkingclassnamesas banned (isBanned: true) across all packages.
|
Size Change: 0 B Total Size: 8.44 MB |
|
Flaky tests detected in f3cab41. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/27220939432
|
What?
Adds a
Bannedversion group tosyncpack.config.mjsso that any package.json declaringclassnamescausesnpm run lint:deps(and CI) to fail.Follow-up to #77950 — picks up the
isBanned classnamessuggestion from @ciampo's review.Why?
Gutenberg standardised on
clsxin #61138 and removed everyclassnamesdeclaration across the monorepo. There is currently no guardrail preventing it from being re-added later — annpm install classnames --workspace @wordpress/<some-pkg>in any workspace would land silently and bloat bundles with both libraries side by side.ESLint's
no-restricted-importsalready catchesimport classnames from 'classnames'at the source level, but not a straypackage.jsondeclaration with no matchingimport— which is exactly what would happen if someone re-adds the dep ahead of refactoring code. Syncpack catches the declaration; ESLint catches the import. Both layers complement each other.How?
Single addition to
syncpack.config.mjs:The rule is purely preventive — no current declarations match, so this PR's diff in actual
package.jsonfiles is empty.Testing Instructions
Testing Instructions for Keyboard
N/A — tooling/config only.
Screenshots or screencast
N/A — no UI changes.
Use of AI Tools
Drafted with assistance from Claude Code. The change and PR description were reviewed and edited by hand.