platinumazure/eslint-plugin-qunit

Ignore `assert` wrapper for `require-expect`

alexlafroscia opened this issue · 4 comments

alexlafroscia commented

We have a function that we often pass assert to in order to read the name of the currently-running test. Typically, this violates the require-expect rule and indicates that the test needs assert.expect added to it.

Since these tests are otherwise structured correctly, and our wrapper function doesn't actually perform any assertions, it would be really nice to be able to configure this plugin so that our particular function doesn't trip up the linter rule.

I totally understand if that's more complexity that you're interested in taking on, but if you're open to it, I would love to make a PR to add this feature!

I am imagining extending the lint rule with some kind of configuration like

{
  allowedAssertWrappers: ['percySnapshot']
}

Where you can provide a list of function names that are ignored when assert is passed to them.

platinumazure commented

Hi @alexlafroscia, thanks for the issue. Sorry for the long delay in responding.

I'm really on the fence about adding this. On the one hand, this is extra complexity and I'm worried about getting more enhancement requests for other ways to ignore specific violations. On the other hand, I can see why it would be a pain to add disable comments for every instance (basically every test, I suppose).

I need to think about it more.

alexlafroscia commented

No problem at all. I may just write a custom rule for my app, taking the code from here and tweaking it to whitelist the needed wrapper function. I completely understand not wanting to add the complexity to your plugin, especially since what I'm running into is certainly an edge case!

  • 👍1
platinumazure commented

If you end up creating that rule and publishing it anywhere, feel free to link it here. I'm curious enough to at least see what it might look like. Of course, you don't have to if you don't want to. Thanks for understanding!

alexlafroscia commented

Totally! Will do.

I'm going to close this under the assumption that complicating the rule in this way isn't something you're interested in. I'll definitely link to my own implementation once that happens, though, in case it comes up for anyone in the future as well!

  • 👍1