Rule 'require-readonly-react-props' not compatible with implicit exact objects #467

mrtnzlml · 2021-03-11T00:16:03Z

Hi! 👋 We are using exact_by_default=true for a while now and this commit motivated me to investigate what it takes to migrate from explicit exact objects {| |} to implicit exact objects { }. It's fairly straightforward and it mostly works well.

However, we are using flowtype/require-readonly-react-props rule which doesn't seem to be compatible with implicit exact objects. It understands only {||} syntax and complains about empty props not being read-only, see:

eslint-plugin-flowtype/src/rules/requireReadonlyReactProps.js

Lines 29 to 32 in e1d5d04

    
           // we consider `{||}` to be ReadOnly since it's exact AND has no props 
        
           if (node.exact && node.properties.length === 0) { 
        
             return true; 
        
           }

I wanted to discuss if you'd be open to changing it and if so, how should the updated rule look like? 🤔 Maybe something like this?

{
    "rules": {
        "flowtype/require-readonly-react-props": ["error", {
            "implicitExactTypes": true // ???
        }]
    }
}

Thanks! 🙂

The text was updated successfully, but these errors were encountered:

Flow standard is now to use `{ }` for strict objects and `{ key: value, ... }` for open objects, see: facebook/relay@6fa0b0d - facebook/flow#8612 - gajus/eslint-plugin-flowtype#467

Brianzchen · 2021-03-15T00:06:15Z

Since there have been no replies, I'll just chime in that the change to the rule looks fine to me. I personally don't use it cause it's a bit extreme and it's not enabled by default from the recommended config so it would never impact me, but given that you can't even use it with an existing rule in this plugin with this one, it makes sense that it gets fixed somehow.

Flow standard is now to use `{ }` for strict objects and `{ key: value, ... }` for open objects, see: facebook/relay@6fa0b0d - facebook/flow#8612 - gajus/eslint-plugin-flowtype#467

mrtnzlml · 2021-03-15T17:14:47Z

Here is my attempt to fix this issue: #471 (5adc5be)

Flow standard is now to use `{ }` for strict objects and `{ key: value, ... }` for open objects, see: facebook/relay@6fa0b0d - facebook/flow#8612 - gajus/eslint-plugin-flowtype#467

This commit adds a support for implicit exact Flow types. This is especially useful when using `exact_by_default=true` Flow option and migrating towards `{ }` and `{ ... }` syntax (Flow standard is now to use `{ }` for strict objects and `{ key: value, ... }` for open objects). Closes: #467

gajus · 2021-04-05T20:39:50Z

🎉 This issue has been resolved in version 5.5.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

Flow standard is now to use `{ }` for strict objects and `{ key: value, ... }` for open objects, see: facebook/relay@6fa0b0d - facebook/flow#8612 - gajus/eslint-plugin-flowtype#467

Flow standard is now to use `{ }` for strict objects and `{ key: value, ... }` for open objects, see: facebook/relay@6fa0b0d and facebook/react-native@00cfb0f This change should be without any problems as longs as users of our NPM libraries are using Flow with `exact_by_default=true` (which is now pretty standard I'd say). Some related (non-blocking) issues: - gajus/eslint-plugin-flowtype#467 - facebook/flow#8612

Flow standard is now to use `{ }` for strict objects and `{ key: value, ... }` for open objects, see: facebook/relay@6fa0b0d and facebook/react-native@00cfb0f This change should be without any problems as longs as users of our NPM libraries are using Flow with `exact_by_default=true` (which is now pretty standard I'd say). Here is how object types behave before this change: ``` type A = { x: number }; // already "exact" type but disallowed because it would be confusing to mix different syntaxes type B = { x: number, ... }; // this is inexact type C = {| x: number |}; // this is explicitly exact and the only allowed way how to describe type "exactness" ``` Here is how object types behave _after_ this change: ``` type A = { x: number }; // this is the only allowed syntax for "exact" type type B = { x: number, ... }; // this is still inexact type C = {| x: number |}; // this is also exact but no longer allowed (so it's not confusing) ``` Some related (non-blocking) issues: - gajus/eslint-plugin-flowtype#467 - facebook/flow#8612

Flow standard is now to use `{ }` for strict objects and `{ key: value, ... }` for open objects, see: facebook/relay@6fa0b0d and facebook/react-native@00cfb0f This change should be without any problems as longs as users of our NPM libraries are using Flow with `exact_by_default=true` (which is now pretty standard I'd say). Here is how object types behave before this change: ``` type A = { x: number }; // already "exact" type but disallowed because it would be confusing to mix different syntaxes type B = { x: number, ... }; // this is inexact type C = {| x: number |}; // this is explicitly exact and the only allowed way how to describe type "exactness" ``` Here is how object types behave _after_ this change: ``` type A = { x: number }; // this is the only allowed syntax for "exact" type type B = { x: number, ... }; // this is still inexact type C = {| x: number |}; // this is also exact but no longer allowed (so it's not confusing) ``` Some related (non-blocking) issues: - gajus/eslint-plugin-flowtype#467 - facebook/flow#8612 adeira-source-id: 5f0c905ae627f670804581f78c1b570f3f71a1e6

This was referenced Mar 11, 2021

Flow: use implicit exact object types adeira/universe#1961

Merged

Missing flowlint for the old exact object type syntax facebook/flow#8612

Closed

mrtnzlml mentioned this issue Mar 15, 2021

feat: add support for implicit exact Flow types #471

Merged

2 tasks

gajus closed this as completed in #471 Apr 5, 2021

gajus added the released label Apr 5, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Rule 'require-readonly-react-props' not compatible with implicit exact objects #467

Rule 'require-readonly-react-props' not compatible with implicit exact objects #467

mrtnzlml commented Mar 11, 2021

Brianzchen commented Mar 15, 2021

mrtnzlml commented Mar 15, 2021 •

edited

Loading

gajus commented Apr 5, 2021

Rule 'require-readonly-react-props' not compatible with implicit exact objects #467

Rule 'require-readonly-react-props' not compatible with implicit exact objects #467

Comments

mrtnzlml commented Mar 11, 2021

Brianzchen commented Mar 15, 2021

mrtnzlml commented Mar 15, 2021 • edited Loading

gajus commented Apr 5, 2021

mrtnzlml commented Mar 15, 2021 •

edited

Loading