@types/json-schema as direct dependency

[Badisi]

Which packages are affected?

• @eslint/compat
• @eslint/config-array
• @eslint/config-helpers
• @eslint/core
• @eslint/mcp
• @eslint/migrate-config
• @eslint/object-schema
• @eslint/plugin-kit

Environment

Node v24.14.1
MacOS

What did you do?

Package @eslint/core has @types/json-schema as a direct dependency:

rewrite/packages/core/package.json

Lines 43 to 45 in c872ca8

	"dependencies": {
	"@types/json-schema": "^7.0.15"
	},

I don't think this is intentional because usually types are not direct dependencies.

What did you expect to happen?

@types/json-schema should be a devDependency.

What actually happened?

I've spotted this while trying to build my own plugin for eslint.
I'm importing a few types from @eslint/core (like ConfigObject, RulesConfig) and due to this tsdown is actually bundling types from json-schema into my d.ts too.

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

I remember reading somewhere that package eslint/config was chosen for being the package reference for types.

• So it's true that I could use import { Config } from 'eslint/config' instead of import { ConfigObject } from '@eslint/core'
• But then it might be worth adding a Rule type into eslint/config too

PS: it doesn't fix the issue here, it's just an additional improvement I'm thinking of 😉

[fasttime]

Thanks for the issue @Badisi. @types/json-schema is intentionally included as a production dependency because it's referenced in the types shipped in the npm package. See #137 (review).

[fasttime]

and due to this tsdown is actually bundling types from json-schema into my d.ts too.

Can you clarify how that is problematic in your use case?

• So it's true that I could use import { Config } from 'eslint/config' instead of import { ConfigObject } from '@eslint/core'

Yes, that's correct.

• But then it might be worth adding a Rule type into eslint/config too

Note that there is no type named Rule. There is a Rule namespace in the eslint types, but I think that's not what you have in mind. To suggest an improvement in the eslint repo, feel free to open an issue there using the change request template.

[Badisi]

Can you clarify how that is problematic in your use case?

Not problematic per se, as I said it's tsdown that was complaining about it, otherwise I won't even have noticed.
But now that I see it, it makes me question concerns about responsibility.

For example with the following:

package.json

{
    "scripts": {
        "build": "tsdown index.ts --dts"
    },
    "peerDependencies": {
        "eslint": ">= 10"
    },
    "devDependencies": {
        "eslint": "^10.2.1",
        "tsdown": "^0.21.10",
        "typescript": "^6.0.3"
    }
}

index.ts

import type { ConfigObject, RulesConfig } from '@eslint/core';
export const config: ConfigObject = {};
export const rules: RulesConfig = {};

Running npm install && npm run build would produce a dist/index.d.mts file with a lot of json-schema types.

But as this piece of code is not using json-schema at all, I find it weird that it should be responsible to ship it.

I would be more inclined to say that @eslint/core should embed them.

---

Note that there is no type named Rule. There is a Rule namespace in the eslint types, but I think that's not what you have in mind. To suggest an improvement in the eslint repo, feel free to open an issue there using the change request template.

Correct, I should have better explain myself here.

My thought are that eslint/config is supposed to be the main reference for typing (if I'm not mistaken) but currently this package doesn't expose much (only Config, defineConfig and globalIgnores), whereas types like Plugin or RuleConfig would also be great to expose as they are mainly used while authoring eslint plugins or shared configs.

So the proposal here is to expose more types from eslint/config (at least Plugin and RuleConfig).

[fasttime]

Running npm install && npm run build would produce a dist/index.d.mts file with a lot of json-schema types.

But as this piece of code is not using json-schema at all, I find it weird that it should be responsible to ship it.

It's true that json-schema isn't used in that code, but @types/json-schema is. For example:

import type { ConfigObject, RulesConfig } from '@eslint/core';
export const config: ConfigObject = {};

// const schema: false | JSONSchema4 | JSONSchema4[] | undefined
const schema = config.plugins?.somePlugin?.rules?.someRule.meta?.schema;

Here, the JSONSchema4 type is imported from @types/json-schema.

@eslint/core itself is a type-only package. If you don't care about types, then you don't need to bundle @eslint/core at all; otherwise, the @types/json-schema types are required.

I would be more inclined to say that @eslint/core should embed them.

Typically ESLint doesn't embed packages only to reduce the dependency tree size.

My thought are that eslint/config is supposed to be the main reference for typing (if I'm not mistaken) but currently this package doesn't expose much (only Config, defineConfig and globalIgnores), whereas types like Plugin or RuleConfig would also be great to expose as they are mainly used while authoring eslint plugins or shared configs.

So the proposal here is to expose more types from eslint/config (at least Plugin and RuleConfig).

The main reference for types is @eslint/core. The eslint/config entry point is mainly intended to re-export utilities included in @eslint/config-helpers. Note that Plugin and RuleConfig are also exposed through the eslint types:

import type { ESLint, Linter } from "eslint";

type Plugin = ESLint.Plugin;
type RuleConfig<Options extends any[]> = Linter.RuleEntry<Options>;

[Badisi]

Here, the JSONSchema4 type is imported from @types/json-schema.

My main issue is why when importing types from @eslint/core, everything has to be bundled into my own dist d.ts.

For example, using this will embed types from @types/json-schema into my final d.ts:

import type { RulesObject } from '@eslint/core';
export const rules: RulesObject = {};

And using this will embed SeverityName, SeverityLevel, Severity, RuleConfig and RulesConfig:

import type { ConfigObject } from '@eslint/core';
export const config: ConfigObject = {};

Whereas this, will only produce import { Config as Config$1 } from "eslint/config"; in my d.ts:
(which is what I would expect)

import type { Config } from 'eslint/config';
export const config: Config = {};

My package is an ESLint plugin, so eslint is part of my peerDependencies.
It will hoist eslint, @eslint/core, eslint/config, @types/json-schema into my consumer's node_modules.
Making all of those packages available via imports.
I don't need to embed anything myself and especially not @types/json-schema if I don't use it explicitly, because, like you, I'm concerned about my bundle size.

---

The main reference for types is @eslint/core. The eslint/config entry point is mainly intended to re-export utilities included in @eslint/config-helpers. Note that Plugin and RuleConfig are also exposed through the eslint types

Taking those examples:

import type { ConfigObject, RulesConfig } from '@eslint/core';


import { type Config, definedConfig } from 'eslint/config';

When authoring my plugin, I often get confused about:

1. which config type to use (Config vs ConfigObject) - only to realize they are the same.
2. where to import rule/rules types from - since Config exists in both places, but rules are only available via @eslint/core.

So naming should be at least consistent, and exports should exists either in one place or both.. to reduce user friction.

[fasttime]

Here, the JSONSchema4 type is imported from @types/json-schema.

My main issue is why when importing types from @eslint/core, everything has to be bundled into my own dist d.ts.

For example, using this will embed types from @types/json-schema into my final d.ts:

import type { RulesObject } from '@eslint/core';
export const rules: RulesObject = {};

Note that there is no type named RulesObject.

And using this will embed SeverityName, SeverityLevel, Severity, RuleConfig and RulesConfig:

import type { ConfigObject } from '@eslint/core';
export const config: ConfigObject = {};

Whereas this, will only produce import { Config as Config$1 } from "eslint/config"; in my d.ts: (which is what I would expect)

import type { Config } from 'eslint/config';
export const config: Config = {};

My package is an ESLint plugin, so eslint is part of my peerDependencies. It will hoist eslint, @eslint/core, eslint/config, @types/json-schema into my consumer's node_modules. Making all of those packages available via imports. I don't need to embed anything myself and especially not @types/json-schema if I don't use it explicitly, because, like you, I'm concerned about my bundle size.

I'm having trouble figuring out your setup. Could you create a repro (like StackBlitz project or GitHub repo) showing the different behavior of import type { ConfigObject } from '@eslint/core' vs. import type { Config } from 'eslint/config'?

When authoring my plugin, I often get confused about:
1. which config type to use (Config vs ConfigObject) - only to realize they are the same.
2. where to import rule/rules types from - since Config exists in both places, but rules are only available via @eslint/core.

So naming should be at least consistent, and exports should exists either in one place or both.. to reduce user friction.

I see. ConfigObject is the better name because it avoids confusion with other config-like types, but probably we can't just drop Config due to compatibility. I'd suggest opening a new issue to request aliasing Config to ConfigObject in @eslint/config-helpers if that matches your intent.