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. One carve-out deliberately keeps it:
# the three zero-consumer pins awaiting a #5835-style ruling
# (@tootallnate/once, react-router, @sveltejs/kit). (`@better-auth/scim` was
# the other carve-out while it held the rc; #3653 moved it onto stable with
# the bound at the major boundary, and #13715 returned its TARGET to the
# family's `^` — see its note below. Both are about the resolved version, not
# the selector shape this rule governs.)
#   - 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 pin sat on the 1.7.0-rc.1
#     PRE-RELEASE while stable 1.7.x shipped the rc.2 REWRITE (no
#     `scimProvider` model, no generate-token endpoint, seven replacement
#     models: scimUser, scimGroup, scimGroupMember, scimSubject,
#     scimConnectionBinding, scimIdentityTombstone, scimProjectionGrant),
#     because moving it was the ADR-0071 feature migration tracked by #3653 —
#     NOT the version bump #3002 did for the rest of the family. That
#     migration has LANDED (#3653, epic #11632): the seven stable models are
#     provisioned as platform objects, connections are runtime data resolved
#     by an application-owned `verifyBearerToken` in plugin-auth, and
#     `sys_scim_provider` retires separately under #11757. The
#     `managedConnections` catalog (three more conditional models) is
#     deliberately NOT adopted — maintainer ruling 2026-08-25, no real
#     customers, no pull.
#     The TARGET is the family's `^1.7.2`. It was held at `1.7.1` EXACT while
#     the family sat on `^1.7.1`; #13715 was the follow-up that ruling named,
#     and it moved the whole family to `^1.7.2` in step — see the comment at
#     the override line below.
#     The rc-era better-call skew is GONE: stable 1.7.1 peers
#     `better-call@1.4.0` exactly — measured unchanged on 1.7.2, the version
#     this lockfile now holds, and still the one better-call copy — so
#     the scaffold `peerDependencyRules` entries for
#     `@better-auth/scim>better-call` retired with the pin move (#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 (their
#     `better-auth>better-sqlite3` and `@better-auth/utils` entries do NOT
#     retire with #3653 — their conditions are separate and unmet).
#     `scripts/check-prerelease-pin-watch.mjs` now has nothing to watch and
#     says so — the self-retiring exit its own header promised.
#   - @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.2'
  '@better-auth/core@<2.0.0': '^1.7.2'
  # scim carries the family's `^` again — see the @better-auth/scim note
  # above. It was held at 1.7.1 EXACT, one deliberate step behind `^1.7.1`,
  # because `^1.7.1` then resolved scim to 1.7.2 while the installed family
  # was still 1.7.1: scim 1.7.2 peers `better-auth`/`@better-auth/core` at
  # `^1.7.2`, and these very overrides would have rewritten those peer ranges
  # down and SILENCED the mismatch rather than satisfy it (#3653 ruling,
  # 2026-08-27, which named the fix as its own follow-up "with the family
  # moved in step, never a side effect of a lockfile refresh"). #13715 IS that
  # follow-up: all eleven members move together in one commit, for the reason
  # the @better-auth/oauth-provider note gives — one line, or better-auth init
  # throws and every auth endpoint 500s.
  # The step is measured gone. `npm view <pkg> dist-tags.latest` reads 1.7.2
  # for all eleven; the install resolves all eleven to 1.7.2 (one copy each),
  # so scim's `^1.7.2` peers are SATISFIED by the installed 1.7.2 pair rather
  # than silenced — the condition the exact hold existed for no longer holds.
  # `^` rather than a fresh exact pin for two reasons. Structural: the two
  # sibling standalone plugins, oauth-provider and sso, peer the family in
  # exactly the same shape (`better-auth`/`@better-auth/core` at `^1.7.2`) and
  # carry `^`; an exact scim would be the one asymmetric member with no reason
  # left to state. Security: this pin is also the GHSA-j8v8-g9cx-5qf4 floor,
  # and a floor that cannot take the next patch is the wrong shape for a
  # package with that history. Measured, so it is not a preference: `^1.7.2`
  # and exact `1.7.2` produce byte-identical resolutions today — two
  # `pnpm install --lockfile-only` runs differ only in the echoed override
  # string and the echoed importer specifier, in no resolved version and no
  # peer-resolution suffix — so the shape is chosen on durability, not on a
  # resolution difference that does not exist.
  # What stays true: the whole family still moves as ONE line, and a bump that
  # moves scim alone is still the mistake the ruling named.
  '@better-auth/scim@<2.0.0': '^1.7.2'
  '@better-auth/oauth-provider@<2.0.0': '^1.7.2'
  '@better-auth/sso@<2.0.0': '^1.7.2'
  '@better-auth/drizzle-adapter@<2.0.0': '^1.7.2'
  '@better-auth/kysely-adapter@<2.0.0': '^1.7.2'
  '@better-auth/memory-adapter@<2.0.0': '^1.7.2'
  '@better-auth/mongo-adapter@<2.0.0': '^1.7.2'
  '@better-auth/prisma-adapter@<2.0.0': '^1.7.2'
  '@better-auth/telemetry@<2.0.0': '^1.7.2'
  '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.
  #     2026-09-03 (#14732): four MORE fast-uri advisories, GHSA-5jgf-p345-68v8,
  #     GHSA-f65p-4m7j-42xc, GHSA-fph4-wmhf-6fwf and GHSA-jqff-g426-hqxp (7.5
  #     high each), fixed in 3.1.6 — target lifted from ^3.1.5, selector stays
  #     at the 4.0.0 boundary. ajv@8.20.0's ^3.0.1 already admits 3.1.6, so
  #     this is a dedupe onto the patched line, not a forced upgrade.
  #   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.6'
  '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'
  # OSV 2026-09-02 (#14639) — four advisories, every one naming a fixed
  # version, so this is the "take the fix" path osv-scanner.toml's own header
  # describes and NOT an exemption; that ledger holds zero entries and the
  # triage ruling is that it stays at zero.
  #   @xmldom/xmldom GHSA-6gmq-8vp8-gcm6 (6.3 medium) — flagged on BOTH
  #     resolved lines: 0.8.13 (fixed 0.8.15) and 0.9.11 (fixed 0.9.12). That
  #     is why this needs TWO selectors and not one. A single lower-bounded
  #     selector at the fixed 0.9.12 would drag the 0.8 consumers across a 0.x
  #     MINOR — the compatibility boundary for a 0.x package — past every
  #     range they declare. Measured dependents and their declared ranges:
  #       0.8.13 <- @authenio/xml-encryption@2.0.2 (^0.8.6),
  #                 samlify@2.13.1 (^0.8.11), xml-crypto@6.1.2 (^0.8.10)
  #       0.9.11 <- @better-auth/sso@1.7.2 (^0.9.10)
  #     Each of those ranges already admits its own fixed version, so both
  #     entries are a dedupe onto the patched line rather than a forced
  #     upgrade past what a dependent supports — the dompurify / nanoid shape
  #     above, and the reason no dependent manifest has to move in lockstep.
  #   qs GHSA-4mjr-xmp4-gh2g and GHSA-x5fp-wj9c-mxmx (6.3 medium each) — one
  #     resolved line, 6.15.3, fixed 6.16.0. Dependents body-parser@2.3.0
  #     (^6.15.2) and express@5.2.1 (^6.14.0) both admit it.
  #   Transitive-only, like dompurify and nanoid above: no workspace manifest
  #     declares either package, so there is no publishable declared range to
  #     keep in lockstep and check-override-consistency.mjs lists both as
  #     overrides it cannot cross-check against a declared range. That is
  #     correct for this shape, and it is a report, never a failure.
  #   Bounds sit at the compatibility boundary — 0.9.0 and 0.10.0 for the two
  #     0.x lines, 7.0.0 for qs — per this block's header rule, never at the
  #     fixed version itself, which would self-invalidate the day that version
  #     is the one flagged (the undici 7.28.0 / brace-expansion 5.0.8
  #     specimens, #4961 / #5032).
  '@xmldom/xmldom@>=0.8.0 <0.9.0': '^0.8.15'
  '@xmldom/xmldom@>=0.9.0 <0.10.0': '^0.9.12'
  'qs@>=6.0.0 <7.0.0': '^6.16.0'