Brett Zamir
Brett Zamir
## Motivation ## Current behavior Should take a look at https://github.com/typescript-eslint/typescript-eslint/tree/main/packages/eslint-plugin to see if its rules can be adapted for use with JSDoc, and if not, consider a [multiple processors...
The following can have fixers added, with some fixers being by option only: - [ ] `check-examples` (for rules that have fixers) - [ ] `check-indentation` - [ ] `check-param-names`...
As raised in #308, contexts where we are checking namepaths in `valid-types` also mistakenly allow for more broad types, e.g.,`Array` should get reported in `@typedef {StringArray} Array` but it currently...
While many of us use and enjoy using closures all over the place (or non-"pure" functions), taking advantage of their ability to borrow from their surrounding context, without any rule...
I'd like to see rules with `contexts` be allowed to specify a special type of context which allows checking particular contexts, including the global context (i.e., a jsdoc block not...
Ensure that the following tags are not present except on their given context (with a few only if another tag is present): - Only on functions or global: `@param`, `@returns`,...
The new `publicOnly` of `require-jsdoc` seems not to be able to handle exports of any of these forms (with `esm: true`) as these fail to report missing jsdoc: - [x]...
For params or properties like: ```js /** * @param {object} cfg * @param {string} cfg.prop1 * @param {boolean} cfg.prop2 */ ``` ...literals like `boolean`, `string`, `void`, etc. should not be...
I think it could be useful for jsdoc to be usable for adding constraints externally to JavaScript source files (akin somewhat to a TypeScript declaration file or a JSON schema...
A couple issues on the new destructuring support: - [x] Where a root and grandchildren are present but not children, the fixing order is off. - [ ] As per...