Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[prefer-readonly-parameter-types] False positive with React.PropsWithChlidren #4492

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.

Sign up for GitHub

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

Jump to bottom
Closed
3 tasks done
mdesantis opened this issue Jan 29, 2022 · 5 comments
Closed
3 tasks done

[prefer-readonly-parameter-types] False positive with React.PropsWithChlidren #4492

mdesantis opened this issue Jan 29, 2022 · 5 comments
Labels
package: eslint-plugin Issues related to @typescript-eslint/eslint-plugin working as intended Issues that are closed as they are working as intended

Comments

@mdesantis
Copy link

mdesantis commented Jan 29, 2022 •
edited
Loading

I have something that I believe is a false positive with React.PropsWithChildren. The following function doesn't break the rule:

function test(
  props: Readonly<Record<string, never>>
): JSX.Element {
  return <div/>
}

But the next one does:

function test(
  props: Readonly<React.PropsWithChildren<Record<string, never>>>
): JSX.Element {
  return <div/>
}

And the next one too:

function test(
  props: Readonly<React.PropsWithChildren<Readonly<Record<string, never>>>>
): JSX.Element {
    return <div/>
}
  • I have tried restarting my IDE and the issue persists.
  • I have updated to the latest version of the packages.
  • I have read the FAQ and my problem is not listed.

Repro

I have created a reproduction sandbox on Glitch: just open the terminal and run npx eslint src/test.tsx.

{
  "rules": {
    "@typescript-eslint/prefer-readonly-parameter-types": 2
  }
}
function test(
  props: Readonly<React.PropsWithChildren<Record<string, never>>>
): JSX.Element {
  return <div/>
}

Expected Result

I expect that Eslint shouldn't report an error

Actual Result

Eslint reports an error:

$ npx eslint src/test.tsx 

/app/src/test.tsx
   8:3  error  Parameter should be a read only type  @typescript-eslint/prefer-readonly-parameter-types
  14:3  error  Parameter should be a read only type  @typescript-eslint/prefer-readonly-parameter-types

✖ 2 problems (2 errors, 0 warnings)

Additional Info

Versions

package version
@typescript-eslint/eslint-plugin 5.10.1
@typescript-eslint/parser 5.10.1
TypeScript 4.5.5
ESLint 8.8.0
node 16.12.0
@mdesantis mdesantis added package: eslint-plugin Issues related to @typescript-eslint/eslint-plugin triage Waiting for team members to take a look labels Jan 29, 2022
@bradzacher
Copy link
Member

Heads up that we have our own playground at https://typescript-eslint.io/

@mdesantis
Copy link
Author

Heads up that we have our own playground at https://typescript-eslint.io/

I noticed it, but:

  1. I can't change package versions there
  2. I can't reproduce the issue there

@bradzacher bradzacher added accepting prs Go ahead, send a pull request that resolves this issue bug Something isn't working and removed triage Waiting for team members to take a look labels Jan 29, 2022
@bradzacher
Copy link
Member

bradzacher commented Jan 29, 2022 •
edited
Loading

Looks like there is a bug in the playground which is breaking the rule - filed #4493.

As for glitch - I don't have the option to open the terminal, so I can't run your repro.
I copied the test code locally against master and it repros:
image

If I had to guess - it's likely one of the recent changes to the underlying tooling that caused this regression.
cc @RebeccaStevens as I know your plugin depends on this tooling.

@bradzacher
Copy link
Member

Actually looking deeper.... I think this is expected behaviour.
PropsWithChildren adds children?: ReactNode to your props.
ReactNode includes a number of object types which are not deeply readonly.
Thus your props are not deeply readonly - causing the rule to error.

It might seem counter-intuitive, but technically without making it deeply readonly - it's valid for you to do like props.children[0].type = 'wrong' within your code (if you narrow the types)
This rule does not enforce shallow readonly, it enforced deep readonly to ensure you cannot mutate the argument.

There's #4436 which adds an ignore list to the rule, which may be of interest if you want to ignore specific types and treat them as always readonly.

@bradzacher bradzacher added working as intended Issues that are closed as they are working as intended and removed bug Something isn't working accepting prs Go ahead, send a pull request that resolves this issue labels Jan 29, 2022
@mdesantis
Copy link
Author

Thank you for the explanation, it feels so obvious now that you figured it out :D I'll try to use the type allowlist as you suggested. Good Saturday!

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 1, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
package: eslint-plugin Issues related to @typescript-eslint/eslint-plugin working as intended Issues that are closed as they are working as intended
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@mdesantis @bradzacher