feat(linter/jsdoc): Implement require-param rule

[leaysgur]

Part of #1170

https://github.com/gajus/eslint-plugin-jsdoc/blob/main/docs/rules/require-param.md

NOTE: config.useDefaultObjectProperties is not implemented for now.

[graphite-app]

Your org has enabled the Graphite merge queue for merging into main

Add the label “merge” to the PR and Graphite will automatically add it to the merge queue when it’s ready to merge. Or use the label “hotfix” to add to the merge queue as a hot fix.

You must have a Graphite account and log in to Graphite in order to use the merge queue. Sign up using this link.

[leaysgur]

$ ./typos .
Warning: "bject" should be "object".
error: `bject` should be `object`
  --> ./crates/oxc_linter/src/rules/jsdoc/require_param.rs:90:14
   |
90 |     "^(?:[oO]bject|[aA]rray|PlainObject|Generic(?:Object|Array))$".to_string()
   |              ^^^^^
   |

How to fix this..?

[codspeed-hq]

CodSpeed Performance Report

Merging #3554 will not alter performance

_{Comparing linter-jsdoc-require_param (45bb316) with main (e8a20f8)}

Summary

✅ 22 untouched benchmarks

[Boshen]

It seems like there is a huge performance regression, would you like to investigate?

[Boshen]

$ ./typos .
Warning: "bject" should be "object".
error: `bject` should be `object`
  --> ./crates/oxc_linter/src/rules/jsdoc/require_param.rs:90:14
   |
90 |     "^(?:[oO]bject|[aA]rray|PlainObject|Generic(?:Object|Array))$".to_string()
   |              ^^^^^
   |

How to fix this..?

I found two intresting cases where we can implement line or block ignore:

• https://github.com/crate-ci/typos/blob/49d37361a04c8119928f7463881fbc32a1c1abd0/crates/typos-cli/tests/cmd/ignore-block.in/_typos.toml
• https://github.com/crate-ci/typos/blob/49d37361a04c8119928f7463881fbc32a1c1abd0/crates/typos-cli/tests/cmd/ignore-line.in/_typos.toml

[leaysgur]

Thanks!

It seems like there is a huge performance regression, would you like to investigate?

Yes..., I will try it later. 😢

[leaysgur]

About previous rules, I have been re-implemented them in an efficient way, by first understanding all the implementation (and test cases and configuration).

However, this time, this rule was so complex and I gave up. So basically code flow is following the original.

Then, how to fix this... 🤔

---

Notes: Add collect_params() to another rules and check whether perf drops or not.

[Boshen]

        let check_types_regex = Regex::new(config.check_types_pattern.as_str())
            .expect("`config.checkTypesPattern` should be a valid regex pattern");

Codspeed to the rescue! Constructing the regex on each turn is expensive! You need to cache it / make it static 😅

[leaysgur]

Oh~~~, thank you very much indeed! (I've just learned such view exists...)

You need to cache it / make it static

I will try! 💪🏻

[leaysgur]

🎉

[Boshen]

Nice work! Learned something new!