Once the ticket is accepted, removal can happen at any time. If you believe that compound components are valuable and wish to make a case for retaining it, please speak up on the issue linked above.
After acceptance, all future notifications around removal will only be posted to the GitHub issue, so be sure to watch that issue if you want further updates.
Oh my gosh… I haven’t used Paragon in a while, and I just went to the (really beautiful!) documentation site to find out what Paragon’s a11y features are around checkboxes, where I found:
Checkbox has been deprecated in favor of Input and ValidationFormGroup
Input is deprecated in favor of Form.Control.
And the interactive code demo doesn’t work when type="checkbox"
Thanks for sharing your concerns! For what it’s worth, the Paragon components currently marked as deprecated have been deprecated for quite awhile now. For example: 1) Checkbox has been deprecated and (mostly) untouched for 4 years; 2) Input was deprecated 2 years ago. We expected that consuming teams would move away from these deprecated components and most have already, as shown by Paragon’s Usage Insights tool.
That said, as you’ve noted, it was a miss to not update the Checkbox component’s deprecation warning to point to Form.Checkbox when the Form.* suite of sub-components were introduced (note: Form.Control intentionally does not have support for the “checkbox” input type). @viktorrusakov has already opened a PR to update these deprecation warnings accordingly.
As @viktorrusakov noted in the DEPR issue linked above, we are also working towards introducing a Paragon CLI that consumers can use to ease upgrades between breaking changes along with helpful developer tools related to the design system. This approach is similar to what many other design systems have in place to reduce the maintenance burden for consuming teams (e.g., Polaris CLI — Shopify Polaris).
[inform] These old, legacy deprecated components will (finally) be removed in the upcoming Paragon release to migrate to design tokens & CSS variables.
Also worth noting, keep in mind Paragon is a community-led design system; in order for it to be scalable given the resources we have for it, its governance model is federated where we have a small (part-time) core team that facilitates/triages the work and strives to get contributions from consuming teams. Only somewhat recently did we get additional resources to have more dedicated engineering support for maintenance, whereby we’re taking advantage of that by executing on maintenance tasks we have historically not been able to do in the past. If you have any feedback/input into how to ease this burden for consumers, we’d love to hear from you and welcome any contributions!
To @AdamStankiewicz and @viktorrusakov and all the contributors to Paragon, I’d first like to apologise for the tone of my post. I took a knee-jerk reaction and made it public without doing my research, or providing a constructive opinion for how to improve the situation. That was irresponsible of me, and disrespectful.
It’s very good to know that you’re tracking usage for these deprecated components, that the long-deprecated components will be removed soon, and that you’re working on a CLI tool to ease upgrades. All of this is fantastic. Carrying the burden of technical debt and transitioning smoothly to new versions is not an easy task, and you’ve been doing your utmost to make this happen.
