Skip to content

Guard the Web runtime dependency graph - #1025

Closed
kiftio wants to merge 1 commit into
mainfrom
chore/web-runtime-dependency-guard
Closed

kiftio wants to merge 1 commit into
mainfrom
chore/web-runtime-dependency-guard

Conversation

@kiftio

@kiftio kiftio commented Nov 2, 2026

Copy link
Copy Markdown
Contributor

Summary

  • add a Web build guard that allows only Checkout Kit workspace packages in shipped runtime dependency fields
  • run the guard as part of dependency linting and before the NPM build

Why

Checkout Kit ships its Web SDK as a single NPM package and CDN artifacts. Today, the shipped Web graph has no third-party runtime dependencies: its components compose through Checkout Kit workspace packages and the build bundles that graph.

The existing lockfile, package verification, and dependency-boundary checks make builds reproducible and validate module boundaries, but they do not prevent a future component from adding a third-party runtime dependency independently. If two shipped modules select incompatible versions of a shared library, dependency resolution can produce multiple bundled copies. This is particularly risky for singleton or global-state libraries, and also increases bundle size and makes security/upgrade ownership ambiguous.

How this helps

The new check rejects dependencies, optionalDependencies, and peerDependencies that are not @shopify/checkout-kit-* workspace:* dependencies in the shipped Web package, components, and internal packages. It intentionally permits devDependencies, so a module can continue to own its test/build tooling without affecting the delivered artifact.

The check runs both in lint:dependencies and before build:npm; therefore package and publish builds cannot silently produce a new runtime dependency graph. Adding a third-party runtime dependency now requires an explicit product-level dependency policy and integration coverage rather than an incidental submodule manifest change.

Examples prevented

  • Two components independently add a shared runtime library with incompatible exact pins, resulting in two copies in the bundled SDK.
  • A component adds a singleton-style dependency whose separate instances disagree on global registration, shared state, or object identity.
  • A runtime dependency is introduced through an optional or peer dependency without a product-level compatibility decision.

Validation

  • dev web lint
  • dev web build

@kiftio
kiftio requested a review from a team as a code owner November 2, 2026 11:47
@github-actions

github-actions Bot commented Nov 2, 2026

Copy link
Copy Markdown

Coverage Report

Status Platform / target Lines Branches Functions Report
⏳ Web — — — Waiting for coverage
⏭️ React Native — — — Not run for this change
⏭️ Embedded Checkout Protocol (TS) — — — Not run for this change

@bitrise

bitrise Bot commented Nov 2, 2026

Copy link
Copy Markdown

✅ E2E not needed

Target Result Test runtime Details Install from branch
React Native · iOS ⏭️ Skipped · not needed for this change — — —
React Native · Android ⏭️ Skipped · not needed for this change — — —
Kotlin · Android ⏭️ Skipped · not needed for this change — — —
Swift · iOS ⏭️ Skipped · not needed for this change — — —

No E2E application was selected for this change.

Bitrise: E2E · iOS CI

@kiftio kiftio closed this Nov 2, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant