chore(eslint-plugin-internal): [no-dynamic-tests] restrict where noFormat can occur#12416
chore(eslint-plugin-internal): [no-dynamic-tests] restrict where noFormat can occur#12416kirkwaiblinger wants to merge 3 commits into
Conversation
|
Thanks for the PR, @kirkwaiblinger! typescript-eslint is a 100% community driven project, and we are incredibly grateful that you are contributing to that community. The core maintainers work on this in their personal time, so please understand that it may not be possible for them to review your work immediately. Thanks again! 🙏 Please, if you or your company is finding typescript-eslint valuable, help us sustain the project by sponsoring it transparently on https://opencollective.com/typescript-eslint. |
|
View your CI Pipeline Execution ↗ for commit fcb7e94
💡 Verify your cache is correct by running tasks in a sandbox. Read docs ↗ ☁️ Nx Cloud last updated this comment at |
✅ Deploy Preview for typescript-eslint ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #12416 +/- ##
==========================================
+ Coverage 87.00% 94.37% +7.37%
==========================================
Files 513 235 -278
Lines 16570 11826 -4744
Branches 5175 3934 -1241
==========================================
- Hits 14417 11161 -3256
+ Misses 1463 285 -1178
+ Partials 690 380 -310
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Great idea!
Just wondering - maybe it should be its own rule? Not sure whether it's related to no-dynamic-tests
There was a problem hiding this comment.
Yeah, I thought about too... But the way I would frame this is: the fundamental issue is that output wasn't being inspected at all by no-dynamic-tests and it should always have been, so I fixed that. Secondarily, I made sure that the existing exception for noFormat was only permitted in the input code rather than being extended to any location in the error object where a string appears. IMO these are both fixes within the existing scope of the rule, not added analysis.

PR Checklist
Overview
I've been seeing various contributors put
output: noFormat`foo`in the test cases lately.For example:
Figured let's use our internal linting to ensure those don't creep in.