Let a config type the modify config options

[JounQin]

modifyEsbuildConfig, modifyRolldownConfig and modifyWebpackConfig were typed as generic functions, and nothing compiles against that:

modifier	<T>(config?: T) => T
config => config	❌ Type 'T | undefined' is not assignable to type 'T'
config => ({ ...config, external: ['dep'] })	❌ Type '{ external: string[]; }' is not assignable to type 'T'
config => { config.external = ['dep']; return config }	❌ Property 'external' does not exist on type 'T'
(config: BuildOptions) => ({ ...config, external: ['dep'] })	❌ Types of parameters 'config' and 'config' are incompatible

The optional parameter types the argument as T | undefined, which can never be returned as T, and the generic return is what rejects a modifier annotated with the bundler's own type.

Why the generic cannot be kept

• Assigning a monomorphic function to a generic signature is by design rather than a gap: <T extends object>(config: T) => T promises "for every T, return that same T", which a modifier typed for one config cannot promise — with T = { a: 1, b: 2 } nothing guarantees the returned object still has b. TypeScript requires the source to be generic as well, and <T extends object>(config: T) => config is accepted, but no config writes that. Upstream: #17574 (open suggestion) and #5494, closed as By Design with this same error.
• The untyped arrow failing is TypeScript's known context-sensitive inference limitation: #47599 "Improve inference in the presence of context-sensitive expressions" (open, Help Wanted, Experimentation Needed). #63545 was closed as a duplicate of it in June 2026, where the answer was "#47599 is not completely solved in 6.0 … any time you have an object literal with unannotated parameters involved in generic inference, that's a context-sensitive inference problem".
• None of it is version-specific: TypeScript 5.4.5, 5.9.2 and 7.0.2 fail these the same way.

What this does instead

modifyEsbuildConfig?: (config: object) => object
modifyRolldownConfig?: (config: object) => object
modifyWebpackConfig?: (config: object) => object

The core does not know the bundlers' types, so the config brings them:

import type { BuildOptions } from 'esbuild'
import type { SizeLimitConfig } from 'size-limit'

export default [
  {
    path: 'index.js',
    modifyEsbuildConfig: (config: BuildOptions) => ({ ...config, external: ['dep'] })
  }
] satisfies SizeLimitConfig

An untyped arrow still compiles; it just checks nothing, and reading or writing the config is what needs the annotation.

The parameter is required, because the plugins always call a modifier with the config they have just built — check.esbuildConfig = check.modifyEsbuildConfig(check.esbuildConfig) in step 20, and the same in the webpack and rolldown plugins. With config? the argument is object | undefined, so a modifier cannot write to the config without handling undefined.

No new dependencies, no peer declarations, no lockfile change. The README line that described the esbuild option as modifying the webpack config is fixed as well.

Verification

• tsc --strict against the real esbuild, rolldown and webpack types: the annotated modifiers above compile, including writing to a webpack config (config.mode = 'production'), under both nodenext and bundler resolution.
• The same config with the parameter left unannotated compiles too.
• A consumer without any of the three bundlers is unaffected: the declaration no longer refers to them.
• oxlint is clean.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[ai]

Honestly, this change doesn't look good. It is very rare feature and we have too many changes which could create issues in the future.

Let's keep simple here and ask user to type config. Is it OK?

[JounQin]

Before deciding, here is what the current declaration actually allows, plus the two alternatives that came up. Measured with tsc --strict against the real esbuild types:

modifier	<T>(config?: T) => T (today)	<T>(config: T) => T	(config: object) => object
config => config	❌ Type 'T | undefined' is not assignable to type 'T'	✅	✅
config => ({ ...config })	❌ Type '{}' is not assignable to type 'T'	✅	✅
config => ({ ...config, external: ['dep'] })	❌ Type '{ external: string[]; }' is not assignable to type 'T'	✅	✅
config => { config.external = ['dep']; return config }	❌ Property 'external' does not exist on type 'T'	❌ same	❌ needs the annotation
(config: BuildOptions) => ({ ...config, external: ['dep'] })	❌ Types of parameters 'config' and 'config' are incompatible	❌ not assignable to type T	✅
(config?: BuildOptions) => ({ ...config, external: ['dep'] })	❌ same	❌ not assignable to type T	✅
<T extends object>(config: T) => config	❌	✅	✅

Nothing compiles against what we have today, not even config => config: the optional parameter types config as T | undefined, which can never be returned as T. The option being .size-limit.js-only is probably why that went unnoticed.

Dropping the ? alone does not get us to "let the user type the config". (config: BuildOptions) => ({ ...config, external: ['dep'] }) is still Type '{ …65 more…; external: string[]; }' is not assignable to type 'T', because a returned object can never be the type parameter, and writing to the config is still Property 'external' does not exist on type 'T'.

So there are two shapes to choose from:

• Drop the generic: modifyEsbuildConfig?: (config: object) => object, with a required parameter — the plugins always call a modifier with the config they have just built (check.esbuildConfig = check.modifyEsbuildConfig(check.esbuildConfig) in step 20). (config: BuildOptions) => ({ ...config, external: ['dep'] }) compiles then, an untyped arrow compiles but checks nothing, and writing to the config needs the annotation. Three declarations plus a doc comment each: no peer dependencies, no @ts-ignore, no lockfile change. Of the three columns above, this is the only one where "ask the user to type config" is true.
• This branch: the bundler's own type without an annotation, at the cost you listed — three optional peers, three ignored imports, a lockfile change.

If the objection is the machinery rather than the option, I will reduce the PR to the first one. If the option is rare enough that its type may stay as it is, that is a decision too — but it is why the current state is worth one of the two, rather than neither.

[ai]

Let's go with Drop the generic, please update PR. User will need to bring own types but it doesn't looks like bad DX:

modifyEsbuildConfig((config: EsbuildConfig) => {
})

[JounQin]

Done — reduced to the three declarations:

modifyEsbuildConfig?: (config: object) => object
modifyRolldownConfig?: (config: object) => object
modifyWebpackConfig?: (config: object) => object

No peers, no @ts-ignored imports, no lockfile change. (config: BuildOptions) => ({ ...config, external: ['dep'] }) compiles now, which is what was missing.

One detail beyond the generic: the parameter is required rather than config?. The plugins always call a modifier with the config they have just built (check.esbuildConfig = check.modifyEsbuildConfig(check.esbuildConfig) in step 20), and with config? the argument is object | undefined, so a modifier could not write to the config without handling undefined itself. Say the word if you would rather keep it optional.

The README line that called the esbuild option's config "webpack" is fixed in the same commit.

[ai]

Thanks. Types was released in 14.2.0.