We pay for sonarqube server but because scans take 2 hours, we use the sonarjs eslint plugin for local development to stop us hitting a blocking issue in sonar later down the pipeline.
When I get diagnostics on rule timings for a local run, I see something like this:
Rule Time (ms) Relative Calls Source
sonarjs/no-trivial-assertions 24946.623 6.5% 1252656 js-plugin
eslint-comments-js/disable-enable-pair 18595.400 4.9% 28389 js-plugin
react/globals 16431.223 4.3% 9679 native
sonarjs/no-duplicate-test-title 13608.637 3.5% 1575892 js-plugin
sonarjs/no-dead-store 12775.747 3.3% 4734293 js-plugin
sonarjs/prefer-specific-assertions 12074.492 3.1% 756656 js-plugin
So I thought I would look at your implementation of no-trivial-assertions and I found its highly inefficient:
There is no caching - so every CallExpression: SonarJS/packages/analysis/src/jsts/rules/S5914/rule.ts at 49ce42de70fcbff3b8b5c65283da7e1a69542396 · SonarSource/SonarJS · GitHub and MemberExpression, for which there are alot in any scanned files - calls through to check for assertions.
The first thing that does, is loop all supported test libraries, seeing if its available.
And that scans all the imports in the file and constructs a import map - per library - per node.
Please add a cache - I would refactor the helpers so per file, you create a helpers context that can cache results (so the cache is just for the rule running on a single file, it would not increase memory usage) - even though this wouldn’t save cross rule work, I believe this would make sonarjs timings similiar to other eslint plugins, instead of being insanely slow.