Repository navigation
Implement integrations crate split and ordered configuration #1237
Description
Description
Track implementation of the design in draft PR #1194: #1194
Use the single spec in that PR as the implementation contract. PRs #1084 and #1016 are historical context, not authoritative direction. Capture the post-prerequisite main baseline and behavioral goldens before extraction.
Milestones
- Crate boundary: introduce
trusted-server-integrationsandtrusted-server-integrations-js; move concrete Rust and browser integration sources, assets, and tests into their respective crates. Keep core and browser core neutral. Preserve the existing operator schema and behavior through the temporary normalizer. - Ordered configuration: adopt one ordered
[integrations]inventory with explicitenabledand auction providers nested under their owning integration. Preserve declaration order through CLI push, stored schema 2, and runtime. Complete migration, dual-read compatibility, and adapter-specific rollout/rollback gates.
Done when
- Each milestone meets its exit criteria in the spec; behavior-preserving moves are reviewed separately from intentional configuration and ordering changes.
- Adapter, CLI, browser, cache, and auction behavior is verified against the baseline except where the spec explicitly changes it; the repository's CI gates pass.
- Schema-2 activation and schema-1 rollback are proven with the spec's per-adapter checks and live-config compatibility gates. Do not cut over an adapter while its safety gate is blocked.
Scope guardrails
No plugin ecosystem, dynamic runtime loading, one crate per vendor, public integration SDK, or unrelated refactor.
Affected areas: Integrations, Core, HTML processing / JS injection, JS build pipeline, adapters, Documentation, and CI / Tooling.
Metadata
Metadata
Assignees
Labels
No labels
Activity
jwrosewell commentedon Nov 3, 2026
@ChristianPavilonis @aram356, now that this is assigned for November, a note on direction before the work starts.
V2 (the 55 pull requests tracked in #777, merged in order) also takes every vendor out of core, but directionally the two designs are not compatible.
trusted-server-integrationsand vendor browser code intotrusted-server-integrations-js, names each integration by an id in one ordered[integrations]inventory, and does not provide for a deployment adding modules of its own.<type>/<vendor>, with a named maintainer. The folder path is the module's name, the settings entries state the run order, and a deployment lists its own module crates in its adapter without changing core.The V2 spec is integration-provider-seam, with the one-crate layout agreed on 23 October in integrations-crate, both in #1342. The associated pull requests are #1348 (the seam, every vendor module out of core), #1351 (page changes as middleware, run in the order the entries give), #1384 (each adapter lists the modules it links) and #1423 (each module's browser script and tests in the crate that supplies it).
Could you evaluate the V2 spec and those pull requests before progressing this issue?