Repository navigation
fix(eslint-config): treat @cedarjs/forms fields as label controls - #2974
Conversation
✅ Deploy Preview for cedarjs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 36 minutes. View limit details
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Summary
Priority: ⬇️ Low Severity of issue fixed: Low Merge Risk: 🔵 Low · up to A narrow accessibility-lint gap remains for labels containing only a hidden InputField. The other configured fields and the customization guidance match their contracts; address or accept this bounded risk before merging. Pre-merge checks |
|
|
|
View your CI Pipeline Execution ↗ for commit 7bf871c
💡 Verify your cache is correct by running tasks in a sandbox. Read docs ↗ ☁️ Nx Cloud last updated this comment at |
|
The changes in this PR are now available on npm. Try them out by running Or try it in a new app with |
jsx-a11y/label-has-associated-controlrecognizes controls only by tag name, so a<label>that wraps a Cedar field component is reported as unassociated:The shared ESLint config (applied when
a11yis enabled incedar.toml, which is the default) now sets the rule'scontrolComponentsoption to every@cedarjs/formsfield component that renders an<input>,<select>or<textarea>.HiddenFieldis not included, because a hidden input can't be labelled. A<label>with no control still errors, so the a11y check stays in effect.<Label>from@cedarjs/formsis not added tolabelComponents. It associates through itsnameprop, which the rule doesn't understand, so the common<Label name="x">Text</Label>usage would start erroring.The forms docs get a short section on nesting fields in a
<label>, including how to setcontrolComponentsfor custom fields or a stricter local config.Fixes #2634