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

Add new shareable configurations for libraries #80

Open
2 of 5 tasks
thomaslombart opened this issue Feb 7, 2020 · 14 comments
Open
2 of 5 tasks

Add new shareable configurations for libraries #80

thomaslombart opened this issue Feb 7, 2020 · 14 comments
Labels
enhancement New feature or request help wanted Extra attention is needed pinned Pinned for different reasons. Issues with this label won't be flagged as stale by stalebot

Comments

@thomaslombart
Copy link
Collaborator

thomaslombart commented Feb 7, 2020

Currently, we are supporting Angular, React and Vue for shareable configurations. The configuration contains the following rules:

  • await-async-query
  • await-async-utils
  • no-await-async-query
  • no-debug
  • no-dom-import

It would be nice to add shareable configurations for other libraries such as:

We would need to check that each rule can be applied to these packages.

@thomaslombart thomaslombart added enhancement New feature or request help wanted Extra attention is needed labels Feb 7, 2020
@Belco90
Copy link
Member

Belco90 commented Feb 7, 2020

Indeed! Would be nice to include all those presets, and even check if there are special cases for them as async fire event for vue so we can add additional rules to those presets in a next step.

I'll try to find more info about what of our current rules could/should be applied for each and share it here for further discussion.

@Belco90
Copy link
Member

Belco90 commented Feb 10, 2020

I did a quick research for Native Testing Library. Even if it's implemented in a completely different way under the hood (as it's not looking for elements in the DOM of course) the main core of the API remains the same. These are the main differences I've found:

  • Additional NativeTestInstance with additional properties. This would need additional rules maybe, but it doesn't affect the current ones.
  • Additional ByHintText query. Just including this one in the list of queries would be enough? It would be enabled for other presets but I don't know if that's a problem.
  • ByRole query doesn't exist. We could disable checks for this query when enabling native testing library preset, but I don't think it's worth the effort?
  • Methods from fireEvent are different. I don't think this affects the plugin as we don't check any specific fireEvent method.

So apart from adding the additional query I don't think we would have to do anything else for that one.

@thomaslombart
Copy link
Collaborator Author

thomaslombart commented Feb 12, 2020

Thanks for the details! For ByHintText and ByRole, I don't think that's a problem. We could do it but as you said, I'm not sure if that's worth.

By the way, there is also a difference for Marko Testing Library for no-dom-import as the package name is @marko/testing-library and not @testing-library/marko.

@Belco90 Belco90 pinned this issue Feb 12, 2020
@Belco90
Copy link
Member

Belco90 commented Feb 12, 2020

Maybe we should split this in a project to be able to implement and review each library separated and then merge everything together.

@SimenB
Copy link

SimenB commented Apr 1, 2020

One not mentioned in the OP is cypress

@Belco90
Copy link
Member

Belco90 commented Apr 1, 2020

@SimenB added to the description! That would need some specific rules I guess so you can limit the queries to only findBy* ones for example.

@SimenB
Copy link

SimenB commented Apr 1, 2020

It seems they'll deal with that themselves

image

But at least prefer-explicit-assert would be nice

@Belco90
Copy link
Member

Belco90 commented Apr 1, 2020

I see, something less to worry about!

For including cypress within prefer-explicit-assert you mean check that all findBy* following the pattern cy.<other optional chained methods>.findByText(<some element>) have a final method right? So:

//  this is fine as it has an assertion
cy.get('form').findByText('Button Text').should('exist')

// this is fine as it's doing something with the element
cy.findAllByText('Jackie Chan').click()

// this should throw an error in the rule for preferring a explicit assert
cy.findAllByText('Hello World')

Is this right? I'm not sure if this is what you meant.

@SimenB
Copy link

SimenB commented Apr 1, 2020

Yeah, that's what I meant 👍

@Belco90
Copy link
Member

Belco90 commented Apr 2, 2020

Cool! It should be easy to implement that. I hope after some internal refactors we are doing we can go back to this ticket. Cypress seems like an easy one to add, probably would be nice start from that one.

@Belco90 Belco90 added this to the new shareable configs milestone Apr 8, 2020
@Belco90
Copy link
Member

Belco90 commented May 29, 2020

React Native Testing Library 2.0 is compatible with the plugin except for one rule! https://callstack.com/blog/react-native-testing-library-2-0/

This will help to create the proper preset for RNTL.

@Belco90 Belco90 unpinned this issue Oct 28, 2020
@Belco90 Belco90 added the pinned Pinned for different reasons. Issues with this label won't be flagged as stale by stalebot label Apr 11, 2021
@MichaelDeBoey MichaelDeBoey removed this from the new shareable configs milestone Apr 25, 2021
@ryanjwessel
Copy link

One thing I noticed when extending the React preset rules for a React Native project, this rule leads to a significant amount of errors: "testing-library/prefer-screen-queries"

React Native Testing Library does not export screen and recommends you destructure the queries from the render method itself.

@Belco90
Copy link
Member

Belco90 commented Jun 4, 2021

Hello @ryanjwessel! We still need to work on proper preset rules for React Native, so I'm afraid the React one won't fit 100%. A good example is prefer-screen-queries, but we need to double-check other rules.

@egemon
Copy link

egemon commented Oct 24, 2023

I used for svelte this one - https://github.com/testing-library/eslint-plugin-testing-library/blob/main/lib/configs/vue.ts
and replaced vue with svelte.
Maybe in case smbd has better rulling - lemme know.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed pinned Pinned for different reasons. Issues with this label won't be flagged as stale by stalebot
Projects
None yet
Development

No branches or pull requests

6 participants