Retire PluginComponentInput stage 2 — delete the deprecated alias (and the now-dead plugin-scope.ts re-export feeding it) #5892

Stage 2 of the two-stage retirement the maintainer ruled on 2026-08-22 (parent #5674, item 13 = A: "mark the alias @deprecated pointing at ComponentInput for one release, then remove").

Stage 1 shipped the deprecation. This card is the removal half, and it is deliberately not ready to dispatch yet — see When below.

What to remove

Two lines, both in @object-ui/types:

1. packages/types/src/index.ts — the ComponentInput as PluginComponentInput, specifier and the @deprecated JSDoc block above it.
2. packages/types/src/plugin-scope.ts — the export type { ComponentInput } from './base.js'; re-export.

The second one is easy to miss and is the reason it is written down here. It is a separate binding from the import type { ComponentInput } from './base.js' at the top of the same file. The import types ComponentMeta.inputs and must stay. The re-export has exactly one consumer — the aliased specifier in index.ts — so it goes dead the moment (1) is deleted. A comment in plugin-scope.ts says so at the site.

Also delete, or convert, packages/types/src/__tests__/plugin-component-input-deprecation.test.ts: it pins "deprecated, not removed", so it is designed to go red when this card lands. That is the pin doing its job, not a regression. Removing the subject removes the pin with it — the same disposition cloud-environment-vocabulary.pin.test.ts got when its subject was deleted.

Bump

minor, with a FROM → TO breaking block in the changeset naming exactly what is no longer exported — the shape both prior published-export removals in this repo used (@object-ui/data-objectstack, CloudOperations and the four-module removal). Never major: this repo's own breaking changes track @objectstack's major, they do not set it.

No compile-compat stub. Same reasoning both precedents record: with no consumer to keep compiling, a stub is a second phantom surface guarding the first.

When

Not before a release actually ships the stage-1 deprecation. The window is the entire point of the two-stage ruling: in-repo the name has zero importers (measured across every root plus the sibling framework repo, with a control), but what cannot be measured from inside this repository is an importer on npm — and that is the claim that licenses deleting an export from a published package. Deleting before the deprecation has shipped gives outside consumers a silent break, which is exactly what the ruling declined to do.

Before landing, re-run the zero-importer measurement rather than trusting this card: it is a claim about the world at filing time.

Verify

node scripts/check-changeset-presence.mjs · check-changeset-no-major.mjs · check-changeset-fixed.mjs · pnpm --filter '@object-ui/types' type-check · pnpm vitest run --project unit packages/types/ · rebuild and diff the emitted dist/index.d.ts so the published surface change is shown, not inferred.

Generated by Claude Code

Generated by Claude Code