Bug: `no-bare-urls` autofix crashes for www autolinks

[tooth-is-silver]

Environment

ESLint version: v10.8.1
@eslint/markdown version: v8.0.3
Node version: v24.14.0
npm version: 11.9.0
Operating System: macOS 26.5 (Darwin 25.5.0)

Which language are you using?

gfm

What did you do?

Configuration

import markdown from "@eslint/markdown";

export default [
    {
        files: ["**/*.md"],
        plugins: { markdown },
        language: "markdown/gfm",
        rules: {
            "markdown/no-bare-urls": "error",
        },
    },
];

I ran ESLint with --fix:

npx eslint --fix test.md

test.md contains:

Visit www.example.com for details.

What did you expect to happen?

ESLint should complete the autofix without throwing an error.
The fixed output should no longer be reported by markdown/no-bare-urls.

What actually happened?

ESLint aborted during autofix:

Error: Custom getRange() method must be implemented in the subclass.
Occurred while linting test.md:1
Rule: "markdown/no-bare-urls"

The rule's first fix replaces www.example.com with <www.example.com>.
Linting <www.example.com> directly reproduces the same error.

Link to Minimal Reproducible Example

https://stackblitz.com/edit/node-jwpkwim7?file=test.md

Participation

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

AI acknowledgment

• I did not use AI to generate this issue report.
• (If the above is not checked) I have reviewed the AI-generated content before submitting.

Additional comments

GFM already recognizes www.example.com as an extended autolink:

https://github.github.com/gfm/#autolinks-extension-

Possible valid fixes include <http://www.example.com> or [www.example.com](http://www.example.com). I think the exact output can be decided separately.

Disclosure: I'm a participant of open source contribution program OSSCA

[DMartens]

Thank you for the issue.
I am able to reproduce the issue.
The problem seems to be that the position data is missing when applying the autofix, which is tracked in the blocked issue #619.
A possible fix would not to provide an autofix for this case.
A PR for this is welcome.

[lumirlumir]

Disclosure: I'm a participant of open source contribution program OSSCA: Confirmed.

---

For the same reasons mentioned in #619 and #620, I’m not sure that fixing only this rule as a workaround is the right approach.

As noted in #620 (review), all Markdown rules assume that the position property exists. So if we review each rule, there may be more edge cases where rules abort due to missing position information.

So I think the following three options could resolve this issue:

• Sending a PR to mdast-util-gfm-autolink-literal would be the right fix for Missing position property for autolinks syntax-tree/mdast-util-gfm-autolink-literal#19.
• If the Mdast team doesn’t accept the PR, forking the extension could be another option, since Markdown’s internal parser, mdast-util-from-markdown, can accept a series of custom plugins, including our forked version.
• If neither of the above is applicable, handling a missing position property in every rule seems like a more graceful approach, since this issue can occur anywhere a GFM autolink literal appears.

FYI, missing position is also considered a bug in another Mdast-compatible parser: bruits/satteri#187

[tooth-is-silver]

Thank you for the detailed feedback.
I understand that disabling the autofix could be a temporary workaround, but it would not address the underlying issue.
I'll wait for further updates on the upstream issue.

[DMartens]

The difference here is that the autofixer creates the problem.
Do I understand correctly that you think the issue should be closed as we already have an issue tracking the missing position property?

[tooth-is-silver]

Sorry for the confusion. I don’t think this issue should be closed yet.

I’ll wait for feedback on the upstream issue about the missing position data.
If there is no progress, I’ll work on the suggested fallback and avoid providing an autofix for this specific case.