Expose the generated types in a stable way

[thebanjomatic]

Tell us about your environment

• ESLint version: 9.39.2
• eslint-plugin-vue version: 10.7.0
• Vue version: 3.4.x
• Node version: 24.18.0

The problem you want to solve.

In 10.4.0 typescript type augmentation of the eslint types was disabled. See #2788

Generally, I'm fine with this, but the types aren't able to be accessed in a consistent and reliable way since previously we could import {RuleOptions as VueRuleOptions} from 'eslint-plugin-vue/lib/eslint-typegen.d.ts' but in 10.7.0, the import path changed to: eslint-plugin-vue/dist/eslint-typegen.d.ts.

Your take on the correct solution to problem.

I'm not a fan of reaching into undeclared exports of a package like this, so a few ideas I guess are:

1. Add an exports field to package.json to declare a ./types export to point to this package.
2. Re-export these types from the index.js

Additional context

[FloEdelmann]

This is similar to #3005, but this time it actually is a user-facing API. So I think introducing exports would be a good idea, e.g. something like this:

"exports": {
  ".": {
    "import": "./dist/index.js", // does this break things, or should we rather leave it out?
    "require": "./dist/index.js",
    "types": "./dist/index.d.ts"
  },
  "./types": "./dist/eslint-typegen.d.ts",
  "./dist": "./dist", // to allow importing utils etc., but not officially supported
  "./lib": "./dist" // same, but maybe this is not even necessary or even confusing?
}

@9romise what do you think?

[thebanjomatic]

A few thoughts:

For correctness, the "types" condition is supposed to go first in order to make sure typescript matches it instead of finding the .d.ts file that sits along-side the .js import. In this case the end result would be the same since it is the same file, but pointing it out because the order of the conditions matters so sorting them is an anti-pattern.

The "./dist" export needs to use a wildcard to be able to match against any files contained in dist and not just the directory itself.

You might also consider adding an export for package.json in case someone is importing/requiring that in order to get the version number or something like that. I found a few instances of people doing that sort of thing with require: https://github.com/search?q=eslint-plugin-vue%2Fpackage.json&type=code

"exports": {
  ".": {
    "types": "./dist/index.d.ts",
    "default": "./dist/index.js",
  },
  "./types": "./dist/eslint-typegen.d.ts",
  "./dist/*": "./dist/*",
  "./package.json": "./package.json"
}

The only question I really have still is should the "./types" export actually be:

"./types": {
  "types": "./dist/eslint-typegen.d.ts"
},

...since there isn't actually a .js file that would be a valid target for an import/require.

[FloEdelmann]

Thanks for your input!

For correctness, the "types" condition is supposed to go first in order to make sure typescript matches it instead of finding the .d.ts file that sits along-side the .js import.

Interesting! For more information, see e.g. this thread: michaelfaith/eslint-plugin-package-json#928

The "./dist" export needs to use a wildcard to be able to match against any files contained in dist and not just the directory itself.

👍
What do you think about exposing ./dist/* also as ./lib/*?

You might also consider adding an export for package.json

👍

The only question I really have still is should the "./types" export actually be:

"./types": {
"types": "./dist/eslint-typegen.d.ts"
},

...since there isn't actually a .js file that would be a valid target for an import/require.

Do you know whether it makes a difference when using it?

[thebanjomatic]

What do you think about exposing ./dist/* also as ./lib/*?

That might smooth over some headaches if someone was previously importing from lib directly prior to 10.7.0 when in was renamed to dist if they are skipping multiple versions, but I would personally be inclined to leave it out.

The only question I really have still is should the "./types" export actually be:

"./types": {
"types": "./dist/eslint-typegen.d.ts"
},

...since there isn't actually a .js file that would be a valid target for an import/require.

Do you know whether it makes a difference when using it?

I would need to do some testing, but since the .d.ts doesn't have any non-type exports, I think it would effectively be the same in most cases. If you were to import or require "eslint-plugin-vue/types" from node, it would probably produce syntax errors (unless you were running in the newish type erasure mode), but if you specified the types condition explicitly I think it would error because the import isn't found. The more explicit error is why I was leaning slightly in that direction.

[9romise]

This is similar to #3005, but this time it actually is a user-facing API. So I think introducing exports would be a good idea, e.g. something like this:

"exports": {
".": {
"import": "./dist/index.js", // does this break things, or should we rather leave it out?
"require": "./dist/index.js",
"types": "./dist/index.d.ts"
},
"./types": "./dist/eslint-typegen.d.ts",
"./dist": "./dist", // to allow importing utils etc., but not officially supported
"./lib": "./dist" // same, but maybe this is not even necessary or even confusing?
}

I think this is a pretty decent fix for now.
But in the next major release, I'd suggest only exporting the files we actually want users to reach, like utils, eslint-typegen.d.ts, instead of the whole dist folder.

[FloEdelmann]

@thebanjomatic would you fancy opening a PR?

[thebanjomatic]

@FloEdelmann see #3013

[thebanjomatic]

@FloEdelmann @9romise sorry to ping you again on this, but is there anything i can do to push this further along?