Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: add no-deprecated-imports rule #127

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

joshblack
Copy link
Member

This is a proof-of-concept for a rule that will help to avoid using deprecated imports from @primer/react. This could be used to encourage use of non-deprecated code and can help with the migration of code from an older format to a newer one.

Would love to hear what folks think about this approach, currently it's being used for a proposal for our v37.x release around SSRProvider and useSSRSafeId usage.

@joshblack joshblack requested review from a team and broccolinisoup December 4, 2023 18:48
Copy link

changeset-bot bot commented Dec 4, 2023

🦋 Changeset detected

Latest commit: 5bd3190

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package
Name Type
eslint-plugin-primer-react Minor

Not sure what this means? Click here to learn what changesets are.

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

@joshblack
Copy link
Member Author

cc @broccolinisoup @pksjce @siddharthkp would love your thoughts here 👀

Copy link
Member

@broccolinisoup broccolinisoup left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for raising this PR! I like the idea! 🙌🏻

It is also good timing that we just chatted with @siddharthkp last week about adding another rule for the title prop that we will deprecate in favor of ActionList.GroupHeading. I like that it is one rule that can take care of all deprecation warning. I have two questions:

  1. Are you thinking this as a complementary practise to TS @deprecated notice?
  2. Can we extend on this rule to create prop/function/component specific rules? Mainly because if we want deprecation rules that have a11y prefixes because they for accessibility improvements (to be able to add to the scorecards). Or maybe we can duplicate this rule and create another one with a11y prefix and we can use this rule for a11y specific deprecations? Or I am very curious to hear if you or anyone else have another idea to address this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants