Skip to content

[prefer-to-have-style] support index accessing of style #264

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

Closed
G-Rath opened this issue May 19, 2022 · 1 comment · Fixed by #266
Closed

[prefer-to-have-style] support index accessing of style #264

G-Rath opened this issue May 19, 2022 · 1 comment · Fixed by #266
Labels
bug Something isn't working released

Comments

@G-Rath
Copy link
Collaborator

G-Rath commented May 19, 2022

This was picked up in the smoke tests.

Currently prefer-to-have-style will error on indexed access of style, e.g.

expect(element.style[1]).toEqual('padding');

It wants you to replace the above with:

expect(element).toHaveStyle('padding');

What I'm not sure is if that by itself is valid as the examples for that matcher only show complete CSS.

Looking at our tests we have this case:

{
code: `expect(el.style).not.toContain("background-color")`,
errors,
output: `expect(el).not.toHaveStyle({backgroundColor: expect.anything()})`,
},

So then the rule should actually already handle this situation for us, we just need to implement support for index accessing - the logic should be something like:

if index access of style, attempt to determine the value being accessed from the matcher, and replace it with toHaveStyle({ <matcher>: expect.anything() });

@github-actions
Copy link

🎉 This issue has been resolved in version 4.0.2 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working released
Projects
None yet
1 participant