Skip to content

Conversation

@outslept
Copy link
Contributor

@outslept outslept commented Sep 27, 2025

What kind of change does this PR introduce?

  • Bugfix
  • Feature
  • Docs
  • Test
  • New Binding issue #___
  • Code style update
  • Refactor
  • Build-related changes
  • Other, please describe:

Does this PR introduce a breaking change?

  • Yes, and the changes were approved in issue #___
  • No

Checklist

  • When resolving issues, they are referenced in the PR's title (e.g fix: remove a typo, closes #___, #___)
  • I have added a convincing reason for adding this feature, if necessary

Other information

  1. "avoid-" mappings (jsx-boolean-value/jsx-fragments). Couldn't find rules with the same name. Do you prefer to keep both or remove "avoid-" mappings?
  2. forbid-component-props: keep it as Partial (there are minor scope/options differences) or mark as Supported? I was unsure.

For most commits, the rationale is already in the PR description; I didn’t duplicate it here.

& WSL kept crashing while editing the docs locally, so I pushed most of my commits via Github's UI. Apologies if there are tiny formatting diffs

Related Issue: #85

Our rule targets anonymous components wrapped in `React.memo`/`forwardRef` and does not flag anonymous default-exported functions (mentioned in docs as `Not supported yet`); context objects are covered by a separate rule; no `ignoreTranspilerName` equivalent - overall not a 1:1 replacement
…-useless-forward-ref` from 🟡 to ✅

Our rule flags forwardRef calls missing the second ref parameter (React.forwardRef and named import); no TS required; semantics match the original rule. Don't get why it was marked as partial

Signed-off-by: Eugene <[email protected]>
…/no-unknown-property` from ✅ to 🔧

Our rule provides auto-fixes (meta.fixable: "code"), so it qualifies as "Fully supported with auto-fix"

Signed-off-by: Eugene <[email protected]>
…horthand-boolean` from ✅ to 🔧.

Our rule provides an automatic fix (meta.fixable: "code"), so it qualifies as "Fully supported with auto-fix".

Signed-off-by: Eugene <[email protected]>
…hand-fragment` from ✅ to 🔧

The rule is auto-fixable

Signed-off-by: Eugene <[email protected]>
…before-spread`, `no-unnecessary-key` alongside `no-missing-key`

Brings parity with `eslint-plugin-react` options (duplicates, key-after-spread, etc.) and makes the migration stricter-by-default

Signed-off-by: Eugene <[email protected]>
…d keep Status ❌

There’s no direct replacement; previous link to no-prop-types was unrelated.

Signed-off-by: Eugene <[email protected]>
@vercel
Copy link

vercel bot commented Sep 27, 2025

@outslept is attempting to deploy a commit to the Rel1cx's projects Team on Vercel.

A member of the Team first needs to authorize it.

@outslept outslept changed the title docs(migration): mark react/display-name mapping as partial docs(migration): refine migration table from eslint-plugin-react Sep 27, 2025
@vercel
Copy link

vercel bot commented Sep 27, 2025

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Preview Comments Updated (UTC)
eslint-react Ready Ready Preview Comment Sep 27, 2025 5:34pm

@Rel1cx
Copy link
Owner

Rel1cx commented Sep 27, 2025

  1. "avoid-" mappings (jsx-boolean-value/jsx-fragments). Couldn't find rules with the same name. Do you prefer to keep both or remove "avoid-" mappings?
  1. forbid-component-props: keep it as Partial (there are minor scope/options differences) or mark as Supported? I was unsure.
  1. The "avoid-" mappings are outdated and can be removed. Their functionality is now handled by jsx-shorthand-boolean and jsx-shorthand-fragment.
  2. I agree with keeping forbid-component-props marked as "Partial".

Don't worry about any minor formatting issues. I'll fix them after the PR is merged.

@Rel1cx Rel1cx requested a review from Copilot September 27, 2025 17:21
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

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

Pull Request Overview

This PR refines the migration documentation table that compares rules from eslint-plugin-react with their ESLint React equivalents. The changes improve accuracy by correcting mappings, status indicators, and adding missing line numbers for better table formatting consistency.

Key changes include:

  • Correcting status mappings for several rules (e.g., display-name, forbid-component-props, forward-ref-uses-ref)
  • Adding comprehensive rule mappings for jsx-key and no-deprecated rules
  • Fixing inconsistent line numbering throughout the table

Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.

Rel1cx and others added 2 commits September 28, 2025 01:22
@Rel1cx Rel1cx changed the title docs(migration): refine migration table from eslint-plugin-react docs(migration): refine migration table from eslint-plugin-react, closes #1154 Sep 27, 2025
@outslept
Copy link
Contributor Author

Okay. If I've missed something let me know 👀

@Rel1cx
Copy link
Owner

Rel1cx commented Sep 27, 2025

LGTM.

@Rel1cx Rel1cx merged commit 973f2cb into Rel1cx:main Sep 27, 2025
7 of 8 checks passed
@outslept outslept deleted the feat/correct-migration-table branch September 27, 2025 17:35
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.

2 participants