pnpm-workspace.yaml

packages:
  - packages/*
  - packages/apps/*
  - packages/drivers/*
  - packages/plugins/*
  - packages/qa/*
  - packages/triggers/*
  - packages/services/*
  - packages/adapters/*
  - packages/connectors/*
  - apps/*
  - examples/*

onlyBuiltDependencies:
  - better-sqlite3
  - esbuild
  - mongodb-memory-server
  - msw
  - sharp

# Transitive-dependency version pins. pnpm v10 reads `overrides` from THIS file
# — the `pnpm.overrides` block in package.json is silently ignored — so all
# pins must live here (previously orphaned in package.json: minimatch, tar).
#
# ⛔ SELECTOR SHAPE — the one rule every OSV pin below now follows (#6095).
# An OSV pin states a FLOOR ("nothing below the patched line"), so its selector
# must cover the whole major it guards and its target must be a range that
# floats up inside that major. Concretely:
#     'pkg@>=<affected floor> <next major above the target>': '^<patched>'
# Never write the selector's exclusive upper bound AT the target's own version
# line (`pkg@<X.Y.Z` -> `^X.Y.Z`). That shape self-invalidates the day X.Y.Z
# itself gets an advisory: you lift the target and the selector silently stops
# covering the very versions you need to rewrite — the live specimen is
# `undici@>=7.23.0 <7.28.0` on the day 7.28.0 was flagged (#4961, #5032).
# With the bound at the major boundary, ONLY the target moves from now on.
# Equally never let the bound sit BELOW the target floor: the old
# `@hono/node-server@<2.0.5` -> `^2.0.10` left the whole 2.0.5 .. 2.0.10 band
# covered by nobody at all (#6095 fixed it).
# For a 0.x line the "major boundary" is the caret boundary (0.35.x -> <0.36.0),
# because that is where semver's compatibility break actually falls.
# `scripts/check-override-consistency.mjs` reports (never fails on) any entry
# that drifts back into the old shape. Two carve-outs deliberately keep it:
# `@better-auth/scim` alone — the rest of the better-auth family was retired to
# the stable `^1.7.1` line with major-boundary bounds when 1.7.0 shipped (#3002),
# and scim's bound MUST stay at the pinned rc, because a `<2.0.0` bound would
# rewrite the stable release DOWN onto the rc it is deliberately held at (#3653)
# — and the three zero-consumer pins awaiting a #5835-style ruling
# (@tootallnate/once, react-router, @sveltejs/kit).
#   - esbuild: GHSA-gv7w-rqvm-qjhr (high). tsup/tsx/vite pulled 0.27.7 / 0.28.0
#     (< 0.28.1); force the patched line everywhere.
#   - form-data: GHSA-hmw2-7cc7-3qxx (high) — CRLF injection via unescaped
#     multipart field names. Pulled 4.0.5 transitively through @vscode/vsce;
#     force the patched >=4.0.6 line. Fails `pnpm audit --audit-level=high` (CI).
#     CONSUMER GONE (#5825): retiring packages/vscode-objectstack took @vscode/vsce
#     with it, and form-data no longer resolves anywhere in the tree — this
#     selector now matches nothing. Kept as defense-in-depth so a future
#     transitive reintroduction lands on the patched line instead of silently
#     re-arming the advisory; dropping a security pin is its own decision, not a
#     rider on a package retirement. Retire it deliberately or not at all.
#   - undici: GHSA-vmh5-mc38-953g (high) — TLS cert validation bypass via
#     dropped requestTls in SOCKS5 ProxyAgent. Pulled 7.27.2 through
#     @vscode/vsce > cheerio (declares undici ^7.19.0); force the patched
#     7.28.0 line (stays in the 7.x major cheerio supports). CI audit gate.
#     Then five more advisories landed on 7.28.0 itself — the version this pin
#     had settled on (GHSA-4cwx-7wf7-3272 7.4 high, GHSA-jr45-8vmc-qm54 5.9,
#     GHSA-8xcm-r25x-g524 / GHSA-v3r7-h72x-cjcm 4.8, GHSA-m8rv-5g2x-5cg5 4.2) —
#     so the target moves to ^7.29.0 (#5032). NOTE the recurring trap this
#     specimen taught: an exclusive upper bound stops covering the very version
#     it pinned once that version is itself flagged — same shape as the
#     brace-expansion 5.0.8 → 5.0.9 lift (#4945). That is why the selector is
#     now `>=7.23.0 <8.0.0` (#6095): the bound sits at the major boundary, so a
#     future lift moves the TARGET alone and the pin never silently misfires.
#     CONSUMER GONE (#5825): cheerio came in only through @vscode/vsce, which
#     left with packages/vscode-objectstack. The two undici copies that remain
#     are @ai-sdk/provider-utils' 7.29.0 and jsdom's 8.9.0. Under the old
#     `<7.29.0` bound BOTH sat outside the selector and it matched nothing;
#     under the `<8.0.0` bound of #6095 the 7.29.0 copy is back in scope (it
#     already satisfies the ^7.29.0 target, so nothing moved — measured), which
#     is exactly the point: the next 7.x advisory will now catch it. jsdom's
#     8.9.0 is a different major and stays outside, unaffected. Kept as
#     defense-in-depth on the same reasoning as form-data above.
#   - @better-auth/scim: GHSA-j8v8-g9cx-5qf4 (high) — account/provider
#     takeover, patched only in >=1.7.0-beta.4. THE ONLY MEMBER OF THE FAMILY
#     STILL ON A PRE-RELEASE, and deliberately so.
#     Stable 1.7.0/1.7.1 have now shipped, and measured against the published
#     1.7.1 tarball they ship the rc.2 REWRITE, not the rc.1 shape: no
#     `scimProvider` model and no generate-token endpoint (0 occurrences in
#     `dist/index.mjs`), replaced by code-defined connections plus six new
#     models (scimUser, scimGroup, scimGroupMember, scimSubject,
#     scimConnectionBinding, scimIdentityTombstone — all six present). So
#     moving this pin is still the ADR-0071 feature migration tracked by #3653
#     (new platform objects, retiring `sys_scim_provider`, a new way for a
#     tenant to register a connection) — NOT the version bump #3002 did for the
#     rest of the family. Holding here stays security-clean: rc.1 is above the
#     >=1.7.0-beta.4 fix floor, and rc.1's peer ranges (`better-auth` and
#     `@better-auth/core` at `^1.7.0-rc.1`) are satisfied by the stable 1.7.1
#     the family now resolves to.
#     KNOWN SKEW while this hold lasts: scim rc.1 peers `better-call@1.3.7`
#     while better-auth 1.7.1 depends on `better-call@1.4.0`. CORRECTION
#     (#10326, measured): the tree does NOT carry two copies — this lockfile
#     holds exactly ONE better-call version, 1.4.0, and scim rc.1 resolves to
#     it, in a scaffolded downstream install too. That is the correct tree
#     rather than a skew to repair: a better-auth plugin has to share the
#     HOST's better-call instance, and the exact `1.3.7` is just the rc's
#     frozen stamp. What the skew does produce is an unmet-peer line on a
#     newcomer's very first `pnpm install`, which the scaffold templates now
#     declare away (see `peerDependencyRules` in
#     `packages/create-objectstack/src/templates/blank/pnpm-workspace.yaml`
#     and `renderPnpmWorkspaceYaml` in `packages/cli`). Measured green on the
#     plugin-auth suite; the skew, and both template entries, retire with
#     #3653.
#     Its sibling line is better-auth's own stale `better-sqlite3@^12.0.0`
#     peer against our `^13.0.3`. That one is NOT reported here, because
#     `auto-install-peers=true` (.npmrc) quietly installs a second, unused
#     better-sqlite3 12.11.1 to satisfy it — which is why CI never saw what a
#     scaffolded project shows on its first screen. #10326 measured 1.7.1 as
#     behaviourally identical on 13.0.3 and 12.11.1 and left this workspace's
#     resolution untouched; only the scaffolds declare it.
#     `scripts/check-prerelease-pin-watch.mjs` keeps watching this pin (it is
#     now the only entry on its watch list) so #3653 has a producer.
#   - @better-auth/oauth-provider: GHSA-p2fr-6hmx-4528 — same better-auth
#     monorepo and same situation as @better-auth/scim above. The fix first
#     shipped in the 1.7.0 pre-release line; it is now in stable 1.7.x, and
#     #3002 moved this pin (and the whole family bar scim) off `1.7.0-rc.2`
#     onto `^1.7.1` — npm `latest` for every family member is 1.7.1, verified
#     by `npm view <pkg> dist-tags`. The 1.7 oauth-provider is exercised on the
#     sign-in path and imports symbols (e.g. CLIENT_ASSERTION_TYPE) that only
#     exist in @better-auth/core 1.7.x, so the ENTIRE family must stay on ONE
#     line — mixing a 1.7 plugin with 1.6.x core throws "Cannot set properties
#     of undefined (setting 'modelName')" during better-auth init and 500s
#     every auth endpoint at runtime. That is now cheap to hold: `better-auth`
#     itself declares EXACT dependencies on the rest of the family
#     (`@better-auth/core`, the five adapters, telemetry all at 1.7.1), so one
#     stable range on the root drags the family with it.
#     The pins are kept rather than dropped because two of them
#     (oauth-provider, scim) are OSV floors: a transitive reintroduction must
#     land on the patched line, and dropping a security pin is its own
#     decision, not a rider on a version bump (same reasoning as form-data /
#     undici above).
#     IMPORTANT: these overrides do NOT ship with published packages — a
#     downstream `npx create-objectstack` install resolves plugin-auth's own
#     declared ranges. plugin-auth therefore declares the same `^1.7.1` in its
#     dependencies (a `^1.6.23` range there resolved to the broken 1.6.23 mix
#     and 500'd every fresh 15.1.0 project). Keep both in sync — CI enforces
#     this via scripts/check-override-consistency.mjs.
#   - uuid: GHSA-w5hq-g745-h8pq (high) — pulled 8.3.2 transitively; the fix
#     first lands in 11.1.1. Pin to the ^11.1.1 LTS line (uuid `legacy-11`
#     dist-tag) rather than the latest major to keep the jump conservative.
#   - postcss: GHSA-qx2v-qp2m-jg93 — a transitive path still resolves 8.4.31
#     (the direct `apps/docs` dep already tracks ^8.5.x); force the patched
#     ^8.5.10 line so the transitive copy is deduped onto it.
#   - cookie: GHSA-pxg6-pf52-xh8x — pulled 0.6.0 transitively; force the
#     patched 0.7.0 line (drop-in compatible).
#   - svelte: GHSA-9rmh-mm8f-r9h6, GHSA-f3cj-j4f6-wq85, GHSA-pr6f-5x2q-rwfp,
#     GHSA-rcqx-6q8c-2c42 — auto-installed (auto-install-peers) as an *optional*
#     peer-of-a-peer via better-auth > @sveltejs/kit at 5.55.3. An `overrides`
#     entry alone can't rewrite this resolution (pnpm rewrites the peer range
#     but leaves the locked 5.55.3), so the patched line is pinned by BOTH this
#     override AND a `svelte: ^5.55.7` devDependency in the root (private)
#     package.json, which gives the peer a concrete version to dedupe onto.
#     Keep both in sync; removing the root devDependency reintroduces 5.55.3.
#   - @tootallnate/once: GHSA-vpq2-c234-7xj6 (low) — pulled 1.1.2 through a
#     legacy agent chain; force the patched 2.0.1 line.
overrides:
  esbuild: '>=0.28.1'
  'minimatch@<11.0.0': '^10.2.3'
  'tar@>=2.0.0 <8.0.0': '^7.5.11'
  'form-data@<5.0.0': '>=4.0.6'
  'undici@>=7.23.0 <8.0.0': '^7.29.0'
  # better-auth family — kept on one line (see @better-auth/oauth-provider note).
  # Off the 1.7.0-rc.2 prerelease and onto the stable line (#3002). Bounds sit
  # at the MAJOR boundary, so a future advisory lift moves only the target.
  'better-auth@<2.0.0': '^1.7.1'
  '@better-auth/core@<2.0.0': '^1.7.1'
  # scim is deliberately held on the 1.7.0-rc.1 PRE-RELEASE, one line behind the
  # rest of the family — see the @better-auth/scim note above. Stable 1.7.x
  # ships the rc.2 rewrite, so adopting it is the ADR-0071 migration (#3653),
  # not this bump. Its bound stays AT the rc on purpose: a major-boundary bound
  # here would rewrite the stable release down onto the rc.
  '@better-auth/scim@<1.7.0-rc.1': '1.7.0-rc.1'
  '@better-auth/oauth-provider@<2.0.0': '^1.7.1'
  '@better-auth/sso@<2.0.0': '^1.7.1'
  '@better-auth/drizzle-adapter@<2.0.0': '^1.7.1'
  '@better-auth/kysely-adapter@<2.0.0': '^1.7.1'
  '@better-auth/memory-adapter@<2.0.0': '^1.7.1'
  '@better-auth/mongo-adapter@<2.0.0': '^1.7.1'
  '@better-auth/prisma-adapter@<2.0.0': '^1.7.1'
  '@better-auth/telemetry@<2.0.0': '^1.7.1'
  'uuid@<12.0.0': '^11.1.1'
  'postcss@<9.0.0': '^8.5.10'
  'cookie@<0.8.0': '^0.7.0'
  svelte: '^5.55.7'
  '@tootallnate/once@<2.0.1': '2.0.1'
  # OSV batch 2026-07 — transitive-only fixes (no publishable package declares these):
  # brace-expansion GHSA-mh99-v99m-4gvg (via minimatch@10.x), then GHSA-rgw5-rvv9-x895
  # (7.5 high) which affects 5.0.8 itself — the version the first pin landed on — so the
  # target moves to ^5.0.9 — the selector keeps its <6.0.0 major boundary (#6095), which is
  # what makes this a target-only lift. Still transitive-only through minimatch (ts-morph, eslint,
  # @typescript-eslint, glob, archiver — @vscode/vsce left with #5825's retirement,
  # the rest still pull it, so this pin stays live); sharp GHSA-f88m-g3jw-g9cj
  # (next optionalDep ^0.34.5 excludes the fix); react-router GHSA-qwww-vcr4-c8h2 has no
  # 7.x fix — fumadocs-core peer allows 8.x and docs uses the next adapter, so jump to 8;
  # @sveltejs/kit GHSA-866w-xmhq-wj7x/GHSA-wqjv-9729-c5q2 (better-auth optional peer);
  # @hono/node-server GHSA-frvp-7c67-39w9 has no 1.x fix — @modelcontextprotocol/sdk
  # declares ^1.19.9 and only imports getRequestListener, which 2.x still exports.
  # ⚠️ @hono/node-server is the exception to this block's "transitive-only" heading:
  # plugin-hono-server declares it directly (^2.0.12). Under the <3.0.0 bound that
  # declaration is now in the selector's scope and the lockfile records ^2.0.10 as its
  # specifier — the resolved version is unchanged at 2.0.12, because the ^2.0.10 target
  # floats to the newest 2.x (measured, #6095).
  'brace-expansion@>=5.0.0 <6.0.0': '^5.0.9'
  'sharp@>=0.34.0 <0.36.0': '^0.35.0'
  'react-router@<8.3.0': '^8.3.0'
  '@sveltejs/kit@<2.69.1': '^2.69.1'
  '@hono/node-server@<3.0.0': '^2.0.10'
  # OSV batch 2026-08 (#5032) — all three name a fixed version, so they are
  # upgrades, not exemptions (the osv-scanner.toml route #4965 defines is for
  # advisories with NO fix and does not apply here):
  #   fast-uri GHSA-7p8r-x3mc-p8w7 (7.5 high) — transitive-only via ajv@8.20.0
  #     (declares ^3.0.1), which reaches @modelcontextprotocol/sdk, objectql,
  #     secretlint and table. Nothing declares fast-uri directly.
  #   hono GHSA-8j4g-w8fx-2239 (5.3) — the one entry here that is NOT
  #     transitive-only: two versions resolved, 4.12.32 from our own packages
  #     and 4.12.33 pulled by @modelcontextprotocol/sdk. The override moves the
  #     transitive copy; the declared ranges are bumped to ^4.12.34 in lockstep
  #     (plugin-hono-server dependency, plugin-auth + @objectstack/hono
  #     devDependencies) so a downstream install — which never sees these
  #     overrides — resolves the same patched line that CI tested. The
  #     @objectstack/hono PEER range stays the permissive ^4.12.8 on purpose: a
  #     peer states what host hono we work against, and a host that pins an old
  #     hono owns that copy; narrowing it fixes nothing here and only breaks
  #     compatibility. check-override-consistency.mjs covers both forms.
  'fast-uri@<4.0.0': '^3.1.5'
  'hono@<5.0.0': '^4.12.34'
  # OSV 2026-08-07 (#6407) — transitive-only, and the same "it has a fix, so
  # take the fix" disposition as the batch above:
  #   dompurify GHSA-55q2-fjhq-7xh7 (5.1 medium) — an IN_PLACE hook removal
  #     leaves a detached subtree executable (XSS). Advisory range is
  #     introduced:0 → fixed:3.4.13, i.e. every version up to and including
  #     3.4.12 is affected, so the selector's floor is the package floor and
  #     only the upper bound needs stating. Transitive-only via mermaid
  #     (apps/docs declares mermaid ^11.16.0; mermaid@11.16.1 declares
  #     dompurify ^3.3.3). Nothing in this workspace declares dompurify
  #     directly, so there is no publishable manifest to keep in lockstep —
  #     check-override-consistency.mjs will list this as an override it cannot
  #     cross-check against a declared range, which is correct for this shape.
  #     ^3.4.13 sits INSIDE mermaid's own ^3.3.3 range, so this is a dedupe onto
  #     the patched line rather than a forced upgrade past what mermaid supports.
  #     Bound at the 4.0.0 major boundary per this block's header rule — never
  #     `<3.4.13`, which would self-invalidate the day 3.4.13 is itself flagged
  #     (the undici 7.28.0 / brace-expansion 5.0.8 specimens, #4961 / #5032).
  'dompurify@<4.0.0': '^3.4.13'
  # OSV 2026-08-08 (#6529) — same "it names a fixed version, so take the fix"
  # disposition as the two batches above; no exemption is involved.
  #   nanoid GHSA-2v37-7h3g-55p8 / CVE-2026-67213 (8.2 high) — a custom
  #     alphabet generator loops forever when `size` is zero, so an
  #     attacker-influenced size is a denial of service. The advisory carries
  #     TWO affected ranges: introduced:0 → fixed:3.3.17, and
  #     introduced:4.0.0 → fixed:5.1.6. Only the first one is live here.
  #     Transitive-only via postcss@8.5.25, which declares nanoid ^3.3.16 and
  #     was the single consumer pulling the flagged 3.3.16 (measured: one
  #     `nanoid:` edge in the whole lockfile). Nothing in this workspace
  #     declares a 3.x nanoid directly, so — exactly as for dompurify above —
  #     check-override-consistency.mjs lists this as an override it cannot
  #     cross-check against a declared range, which is correct for this shape.
  #     ^3.3.17 sits INSIDE postcss's own ^3.3.16 range, so this is a dedupe
  #     onto the patched line, not a forced upgrade past what postcss supports.
  #     ⚠️ The four drivers that declare nanoid ^6.0.0 (driver-mongodb,
  #     driver-sql, driver-sqlite-wasm, driver-turso) are deliberately OUT of
  #     this selector: 6.0.0 is above the advisory's second fixed line (5.1.6)
  #     and is not affected, and the <4.0.0 bound is what keeps it that way —
  #     a bound written at the package ceiling would have dragged that whole
  #     major back onto the 3.x line.
  #     Bound at the 4.0.0 major boundary per this block's header rule — never
  #     `<3.3.17`, which would self-invalidate the day 3.3.17 is itself flagged
  #     (the undici 7.28.0 / brace-expansion 5.0.8 specimens, #4961 / #5032).
  'nanoid@<4.0.0': '^3.3.17'