Environment

ESLint version: v9.24.0
@eslint/markdown version: v6.3.0
Node version: v20.18.0
npm version: v10.9.2
Operating System: Windows 11

What problem do you want to solve?

Hello,

While working on the issue #336, I came across another interesting problem related to the MarkdownSourceCode object.

Currently, we're extending the TextSourceCodeBase class from @eslint/plugin-kit, which is intended to define a common interface for language-specific implementations.

However, when we extend this class without overriding certain types, the node type remains as object.

For example, assuming #336 is accepted:

• The getText() method takes a node parameter of type object because it's inherited from the TextSourceCodeBase superclass.

• On the other hand, the getParent() method takes a node of type MarkdownNode, since it's defined in the MarkdownSourceCode subclass.

If #336 is accepted, rules can be defined without type-related issues.

However, considering the purpose of TypeScript, narrowing the types would lead to a more stable and robust codebase overall.

So I’d like to propose adding proper type narrowing in the MarkdownSourceCode implementation.

What do you think is the correct solution?

I think one possible approach is to override the existing methods.

/**
 * Markdown Source Code Object
 * @implements {TextSourceCode}
 */
export class MarkdownSourceCode extends TextSourceCodeBase {
    // ...

    /**
     * Gets the source code for the given node.
     * @param {MarkdownNode} [node] The AST node to get the text for.
     * @param {number} [beforeCount] The number of characters before the node to retrieve.
     * @param {number} [afterCount] The number of characters after the node to retrieve.
     * @returns {string} The text representing the AST node.
     * @public
     */
    getText(node, beforeCount, afterCount) {
        return super.getText(node, beforeCount, afterCount);
    }

    // ...
}

By using super, we don't need to re-implement the existing behavior, and we can also provide more specific JSDoc comments tailored for Markdown.

Participation

• I am willing to submit a pull request for this change.

Additional comments

This problem also happens in JSON too!