Let's make sure that the types test is passing. That should cover our bases when it comes to exported types.

npm run test:types (note: this is currently failing in CI)

Thanks for sending a PR! I just noted down what I noticed.

Currently, MarkdownNode, SourceLocation, and SourceRange are missing.

Also, many of the types that were originally exported from index.d.ts are now missing. For example:

We used to be able to access these exported types, but now many of them are no longer accessible.

I don't think all of the types from @eslint/core necessarily need to be exported from this package. People can just use @eslint/core directly for that.

Similar to the CSS and JSON plugins, I've modified the test to import SourceLocation and SourceRange from '@eslint/core'.

I’m not sure how other team members feel about this, but I’d like to point out that the current change introduces a Breaking Change.

For example,

In my custom Markdown plugin, I imported the ParserMode type from @eslint/markdown.

However, with this change, the ParserMode type is no longer exported directly from @eslint/markdown. ParserMode type now lives in dist/esm/language/markdown-language.d.ts, and the current package.json does not export that path.

As a result, users can no longer access it via:

• @eslint/markdown
• or even an alternative path like @eslint/markdown/esm/....

• Current package.json export map:

  "exports": {
    ".": {
      "types": "./dist/esm/index.d.ts",
      "default": "./dist/esm/index.js"
    },
    "./types": {
      "types": "./dist/esm/types.d.ts"
    }
  },

• Problem - parserMode type is no longer accessible:

But is this issue limited to just ParserMode type? I’d argue no.

As I mentioned in this earlier comment, some types were not explicitly exported from index.js.

However, thanks to Rollup’s behavior, the generated dist/esm/index.d.ts file exposed those types as if they were hoisted. This allowed users to import all types - even those not defined in index.js - directly from @eslint/markdown without any issues.

One such example is ParserMode. But other types may have been exposed in the same way, and if users were relying on them, this change could silently break their code.

While I agree that explicitly importing types from @eslint/core is a better and more intentional approach moving forward, introducing this change without clearly marking it as a breaking change could lead to confusion for users.

So, I'd like to ask the team to reconsider this issue.
If it's okay to keep this change without an explicit breaking change notice, I'm happy to follow that decision :)

Refernece: #367 (comment)

This is actually part of the reason I wanted to make this change. ParserMode is not intended to be exported, but due to the limitations with the way this package was written, it was exported. It's only used by MarkdownLanguage, which is not exported, so it's really just an internal type that should be of no use outside of the package.

I'm okay with marking this as a breaking bug fix if others agree.

I agree with marking this PR as a breaking change 👍

Could other team members share their thoughts on this? @eslint/eslint-team @eslint/eslint-tsc

As a breaking change, we should hold off on merging this until we do another patch release to incorporate the non-breaking PRs that are in review currently.