`jsdoc/no-restricted-syntax`: `context` does not support full range of selectors if any other `context` is `any/*`

[budjmt]

Expected behavior

I am able to use the full range of AST selectors with no-missing-syntax; I would expect no-restricted-syntax to have parity, regardless of which other contexts are used

Actual behavior

error Syntax is restricted: undefined jsdoc/no-restricted-syntax
Note that the configured message is also not used

ESLint Config

parser is @typescript-eslint/parser, this is the only rule needed:

"jsdoc/no-restricted-syntax": [ "error", {
            "contexts": [
                {
                    "context": "any",
                    "comment": "JsdocBlock[postDelimiter='']:has(JsdocTag ~ JsdocTag[tag=/private|protected/])",
                    "message": "Access modifier tags must come first"
                },
                {
                    "context": ":declaration:not(TSEnumDeclaration):not(:has(ObjectExpression)), :function",
                    "comment": "JsdocBlock[postDelimiter='']:has(JsdocTag[tag='enum'])",
                    "message": "@enum is only allowed on potential enum types"
                },
            ]
        } ]

If the other rule is deleted or the context is changed to something else (excluding *), the context is interpreted correctly

ESLint sample

/**
 * @enum {String}
 * Object holding values of some custom enum
 */
const MY_ENUM = Object.freeze({
  VAL_A: "myvala"
} as const);

Environment

• Node version: 16.13.1
• ESLint version 8.4.1
• eslint-plugin-jsdoc version: 37.2.2

[gajus]

🎉 This issue has been resolved in version 37.2.5 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[brettz9]

Thank you for the report. Turns out we had two problems. One was that there was indeed a specific issue with no-restricted-syntax that could cause it to report just because there was a context match (without a comment match). Another more serious issue was that if one reused the same context, the old value would be overwritten. Both of these issues should now be fixed.

However, I think there may be still one issue remaining (I believe with no-restricted-syntax alone); namely, if there is an "any" context, only handling for such a context occurs.

[brettz9]

Ok, should now hopefully be all fixed in v37.2.6.

[brettz9]

Sigh, still one more was needed: 37.2.7

[budjmt]

Thanks for the quick response!!