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

Compatibility with eslint-plugin-testing-library #295

Open
thymikee opened this issue May 11, 2020 · 6 comments
Open

Compatibility with eslint-plugin-testing-library #295

thymikee opened this issue May 11, 2020 · 6 comments

Comments

@thymikee
Copy link
Member

@thymikee thymikee commented May 11, 2020

Describe the Feature

It would be lovely to verify that our library is compatible with eslint-plugin-testing-library, determine what's missing and plan the necessary work to make it usable.

Possible Implementations

I'd like avoid creating another plugin based on the existing one. I'd prefer documenting the shortcomings (e.g. lack of screen if there are rules for that)

@thymikee
Copy link
Member Author

@thymikee thymikee commented May 11, 2020

@thymikee
Copy link
Member Author

@thymikee thymikee commented May 18, 2020

@cross19xx please put your findings here :)

@cross19xx
Copy link
Member

@cross19xx cross19xx commented May 18, 2020

With the exception of the following syntaxes, all other rules are valid and compatible with eslint-plugin-testing-library.

  • no-debug: Using the default debug is seen as a valid syntax, whereas using the debug inside the render method is seen as an invalid syntax, i.e.

    // Valid syntax
    import {debug} from 'react-native-testing-library';
    debug(<Component />);
    
    // Invalid syntax
    import {render} from 'react-native-testing-library';
    const {debug} = render(<Component />);

    Luckily, react-native-testing-library@next covers this.

  • prefer-wait-for: This is shown as an invalid syntax the wait method in RNTL is waitForElement. A suggestion will be to have an alias for waitForElement as waitFor. Depending on the state of this (i.e. if on or off), no-wait-for-empty-callback may be triggered

  • prefer-screen-queries. This will require having a screen object.

@thymikee
Copy link
Member Author

@thymikee thymikee commented May 18, 2020

Thanks! Now w need to document it

@BatDroid
Copy link
Contributor

@BatDroid BatDroid commented Oct 4, 2020

@thymikee could you please explain a bit more about what should be documented. I would love to start my contribution on this repo

@thymikee
Copy link
Member Author

@thymikee thymikee commented Oct 4, 2020

  • prefer-screen-queries. This will require having a screen object.

Only this one is relevant now, since we don't have screen queries.

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

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.