Bug: `@eslint/object-schema` missing some type exports

[Pixel998]

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 version: v24.12.0
npm version: v11.6.2
ESLint version: v9.39.2
Operating System:

What did you do?

Tried to import various types:

import type {
  BuiltInMergeStrategy,
  BuiltInValidationStrategy,
  ObjectDefinition,
  PropertyDefinition,
} from "@eslint/object-schema";

What did you expect to happen?

All four types (BuiltInMergeStrategy, BuiltInValidationStrategy, ObjectDefinition, PropertyDefinition) should be exported from the main package and importable.

These types are defined in the package's types.ts file and should be part of the public API.

What actually happened?

Inconsistent behavior:

• ✅ ObjectDefinition and PropertyDefinition types import successfully
• ❌ BuiltInMergeStrategy and BuiltInValidationStrategy types cause TypeScript errors:

'"@eslint/object-schema"' has no exported member 'BuiltInMergeStrategy'.
'"@eslint/object-schema"' has no exported member 'BuiltInValidationStrategy'.

Link to Minimal Reproducible Example

https://stackblitz.com/edit/typescript-node-cvmp1yvy

Participation

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

Additional comments

No response

[fasttime]

It makes sense to export BuiltInMergeStrategy and BuiltInValidationStrategy since those types are used in the definition of PropertyDefinition, which is exported.

rewrite/packages/object-schema/src/types.ts

Lines 36 to 46 in e976d60

	/**
	* The strategy to merge the property.
	*/
	// eslint-disable-next-line @typescript-eslint/no-explicit-any -- https://github.com/eslint/rewrite/pull/90#discussion_r1687206213
	merge: BuiltInMergeStrategy | ((target: any, source: any) => any);
	/**
	* The strategy to validate the property.
	*/
	// eslint-disable-next-line @typescript-eslint/no-explicit-any -- https://github.com/eslint/rewrite/pull/90#discussion_r1687206213
	validate: BuiltInValidationStrategy | ((value: any) => void);

Probably we never noticed the issue before due to the lack of type tests.

[Pixel998]

@fasttime Looking at the built output, we have two separate declaration files in the package:

1. index.d.ts - Contains ObjectDefinition and PropertyDefinition (the types that were referenced in JSDoc comments in our source files)
2. types.d.ts - Contains ALL types from types.ts including BuiltInMergeStrategy and BuiltInValidationStrategy

The problem is our package exports only give users access to index.d.ts, not types.d.ts. This appears to affect all the other packages too (see #351).

One solution is to add a dedicated export for types like @eslint/json does. Though there's an open issue (eslint/json#130) requesting types be exported from the main entry point instead of a /types subpath. What are your thoughts?

[fasttime]

@fasttime Looking at the built output, we have two separate declaration files in the package:

1. `index.d.ts` - Contains `ObjectDefinition` and `PropertyDefinition` (the types that were referenced in JSDoc comments in our source files)

2. `types.d.ts` - Contains ALL types from `types.ts` including `BuiltInMergeStrategy` and `BuiltInValidationStrategy`

The problem is our package exports only give users access to index.d.ts, not types.d.ts. This appears to affect all the other packages too (see #351).

One solution is to add a dedicated export for types like @eslint/json does. Though there's an open issue (eslint/json#130) requesting types be exported from the main entry point instead of a /types subpath. What are your thoughts?

I think the simplest solution for the moment is adding type definitions for BuiltInMergeStrategy and BuiltInValidationStrategy alongside the existing ones in object-schema.js:

rewrite/packages/object-schema/src/object-schema.js

Lines 16 to 17 in cb858ff

	/** @typedef {import("./types.ts").ObjectDefinition} ObjectDefinition */
	/** @typedef {import("./types.ts").PropertyDefinition} PropertyDefinition */

I wouldn't go the step of changing the project structure for a total four exported types. From what I understand, the suggested approach for eslint/json#130 would make a /types entry point unnecessary by ensuring that any types in types.ts are automatically exported by the main entry point, which seems like a nice solution as well.