Bryan Mishkin
Bryan Mishkin
I'm leaning toward a single `type-checked` config as likely making the most sense in our case rather than having a type-aware version of every one of our many configs (`recommended-type-checked`,...
I'll have to look back at the PRs that added those configs to see if there was any explanation mentioned for adding them. However, they are theoretically useful for reducing...
@jaswilli that's a fair point, although I'm not yet sure I agree. Can you open up a new issue for us to discuss that?
Yes definitely let's get a minor version out first.
We could optionally hold off on releasing v9 until ESLint v9 is out so that we can ensure that both v8 and v9 are compatible with it first.
We can keep the discussion about v8.1.2 in here: * https://github.com/platinumazure/eslint-plugin-qunit/pull/532
You need to add "closes #203" to the PR description to correctly link the issue to the PR.
Out of curiosity, what kind of use cases do you see [`assert.expect(n)`](https://api.qunitjs.com/assert/expect/) being valuable for? And are those use cases common? Teams and codebases I have worked in moved to...
@raycohen makes sense on your first point, I'll remove that. One of the goals of this rule would be to catch assertions that we know will fail due to the...
@mongoose700 that's true, although I wasn't originally planning to take TypeScript information into account in this rule. Considering TypeScript types when available is a good idea, although I want this...