Bug: ESLint 9.39.0 breaks the downstream Markdown plugin build

[lumirlumir]

Environment

ESLint version: 9.39.0
@eslint/markdown version: 7.5.0
Node version: 20.19.4
npm version: 10.9.2
Operating System: Windows 11

Which language are you using?

commonmark

What did you do?

ESLint 9.39.0 breaks the downstream Markdown plugin build.

• CI: https://github.com/lumirlumir/npm-eslint-plugin-mark/actions/runs/19021277779/job/54316764504?pr=377
• Version Bump PR: chore(deps-dev): bump eslint from 9.38.0 to 9.39.0 lumirlumir/npm-eslint-plugin-mark#377

What did you expect to happen?

There should be no CI failures.

What actually happened?

It seems that this bug is also related with the one from eslint/rewrite#309.

Currently, @eslint/markdown@7.5.0 depends on @eslint/core@0.16.0, which appears to be causing the bug.

When I add overrides field to the root-level package.json as follows, the bug disappears:

  "overrides": {
    "@eslint/core": "^0.17.0"
  }

---

I think the correct solution would be to release a new version that depends on @eslint/core@0.17.0.

Also, this applies to json and css plugins, since their current @eslint/core version was not bumped to @eslint/core@0.17.0.

(I have another repository where @eslint/json causes an error; if this needs to be addressed for the rationale of releasing a new version, I can open a separate issue.)

Link to Minimal Reproducible Example

lumirlumir/npm-eslint-plugin-mark#377

Participation

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

Additional comments

No response

[nzakas]

Agreed.

This also means that Renovate is still not sending PRs immediately for @eslint/* dependencies, otherwise we would have caught this earlier.

[lumirlumir]

(FYI, the same error in JSON plugin: eslint/json#178)

[aladdin-add]

Renovate upgraded it in #572. The issue is that it was tagged as "chore", and release-please simply ignored it instead of creating a new version.

we can change the tag "chore" => "fix"?

[lumirlumir]

Maybe, there is a pending release PR (#576), and the version upgrade in #572 is already included in HEAD, so I think releasing #576 is sufficient?

[aladdin-add]

As of now it's working. But I'm a bit worried it might reappear - every time after an update while we want to release a version. 🤔

[lumirlumir]

Unfortunately, builds often fail after a minor release of eslint and @eslint/core because eslint and plugins such as @eslint/markdown or @eslint/json can end up depending on different @eslint/core versions.

I've run into this issue about three times (including this one) with my custom Markdown plugin. (I didn't report the earlier occurrences at that moment, and I just waited for a new @eslint/markdown release instead.)

There are probably few authors creating custom Markdown (or JSON, CSS) plugins now, so this seems rarely reported.

[fasttime]

It looks like @html-eslint/eslint-plugin also depends on @eslint/core@0.15.2 via @eslint/plugin-kit and so it also breaks with new versions of ESLint that depend instead on @eslint/core@0.17.0. This has been already noted in eslint/eslint#20286 (comment). v0.15.x and v0.17.x are technically different minor releases of @eslint/core but a version range like "^0.15.2" will not automatically update from v0.15.2 to v0.17.0, so we will end up using an outdated version of the core types in other packages every time the minor version number is bumped.

I'm thinking of how to best deal with with this situation. We could for example update our release workflow to increase only the patch version number of @eslint/core when a feat: is merged, instead of the minor version number, which would allow npm to update the types automatically. Alternatively, we could broaden the dependency range to something like "@eslint/core": ">=0.17.0 <1" in other packages to make sure that npm can pick up non-breaking changes automatically, like it does for minor releases of other packages. We could also publish patched versions of @eslint/core v0.15.x and v0.16.x to include the more recent fix: PRs, but I think that's not a long-term solution.

[fasttime]

Another fairly easy fix would be switching @eslint/core the regular 1.0.0 release. That would avoid having to deal with all the quirks of semver pre-releases.