Files
twenty/package.json
T
Raphaël Bosi 45a2d1ce97 fix(storybook): prevent oversized Argos screenshots (#25779)
Argos's Storybook capture enlarged viewport-sized stories after applying
CSS zoom, and the affected SDK did not reliably restore the iframe
between captures. This produced the 9600×7392 screenshot in build 5574
and contributed to the visual comparison worker repeatedly running out
of memory.

Pin `@argos-ci/storybook` to 6.2.3 in twenty-front and twenty-ui for the
iframe-restoration fix, set the frontend preview's fit-to-content zoom
to 1, and make the frontend browser viewport explicit at 1200×900. Keep
the dependency explanation and lockfile aligned with the exact version.

Validation:

- Frontend direct type check and formatting pass.
- The existing SettingsSubdomain story suite was verified with this SDK
and capture configuration: all five stories passed, and Reserved
Subdomain produced a 1200×916 screenshot.
- Full-file lint still flags the pre-existing mock-image color in
preview.tsx.

Rollout: deploy the companion Argos worker guard first. After merging
this capture fix, establish a fresh main-branch baseline and rerun PR
visual builds because screenshots now use 1× zoom. Worker memory remains
unchanged.

Companion PRs: [Argos worker
guard](https://github.com/twentyhq/twenty-argos/pull/13), [Factory
upload validation](https://github.com/twentyhq/twenty-factory/pull/115).
2026-09-11 13:17:45 +00:00

90 lines
19 KiB
JSON

{
"private": true,
"devDependencies": {
"@nx/jest": "22.7.8",
"@nx/js": "22.7.8",
"@nx/react": "22.7.8",
"@nx/storybook": "22.7.8",
"@nx/vite": "22.7.8",
"@nx/web": "22.7.8",
"@types/react": "^19.2.0",
"@types/react-dom": "^19.2.0",
"@yarnpkg/types": "^4.0.0",
"concurrently": "^8.2.2",
"http-server": "^14.1.1",
"nx": "22.7.8",
"oxfmt": "0.50.0",
"tsx": "^4.17.0",
"verdaccio": "^6.3.1"
},
"engines": {
"node": "^24.5.0",
"npm": "please-use-yarn",
"yarn": ">=4.0.2"
},
"license": "AGPL-3.0",
"name": "twenty",
"packageManager": "yarn@4.13.0",
"resolutions": {
"@module-federation/dts-plugin/undici": "^7.29.0",
"zapier-platform-core/form-data": "4.0.6",
"@remote-dom/react/@types/react": "^19.2.0",
"graphql": "16.8.1",
"graphql-redis-subscriptions/ioredis": "5.10.1",
"@types/qs": "6.9.16",
"@opentelemetry/api": "1.9.1",
"chokidar": "^3.6.0",
"tmp": "^0.2.7",
"@angular-devkit/core": "19.2.24",
"yeoman-environment": "6.0.1",
"express/qs": "6.15.2",
"googleapis/googleapis-common": "8.0.1",
"@cyntler/react-doc-viewer/ajv": "8.20.0",
"front-matter/js-yaml": "4.3.1",
"@lingui/cli/esbuild": "0.28.1",
"@opennextjs/aws/esbuild": "0.28.1",
"zapier-platform-cli/esbuild": "0.28.1",
"front-matter@npm:4.0.2": "patch:front-matter@npm%3A4.0.2#~/.yarn/patches/front-matter-npm-4.0.2-e1cc0efa69.patch",
"@react-email/ui/next": "16.3.2",
"zapier-platform-cli/adm-zip": "0.6.0",
"@module-federation/dts-plugin/adm-zip": "0.6.0"
},
"//resolutions": "Each entry is load-bearing: it forces a version OUTSIDE some parent's declared range where no fixed upstream release exists; remove each once its blocker ships. @module-federation/dts-plugin/undici ^7.29.0 -> five undici advisories with in-major fixes (6.28.0 / 7.29.0 / 8.9.0): CVE-2026-13697 / GHSA-4cwx-7wf7-3272 (critical, cross-user information disclosure + parse-time crash via degenerate private cache directives) and CVE-2026-14643 / GHSA-jr45-8vmc-qm54, both >=7.0.0 <7.29.0 and >=8.0.0 <8.9.0, plus CVE-2026-15157 / GHSA-m8rv-5g2x-5cg5, CVE-2026-16728 / GHSA-8xcm-r25x-g524 and CVE-2026-16729 / GHSA-v3r7-h72x-cjcm (those three also <6.28.0). ^7.29.0 also still covers the six 7.28.0-fixed advisories the previous dts-plugin/undici ^7.28.0 entry was added for (GHSA-pr7r-676h-xcf6, GHSA-35p6-xmwp-9g52, GHSA-p88m-4jfj-68fv, GHSA-g8m3-5g58-fq7m, GHSA-hm92-r4w5-c3mj, GHSA-vmh5-mc38-953g). @module-federation/dts-plugin 2.5.1 pins undici 7.24.7 exact (latest 2.8.1 pins 7.28.0 exact, still vulnerable; transitive via @module-federation/cli + enhanced), so no parent upgrade carries the fix; scoped ^7.29.0 to stay inside major 7 -- no v8 API jump -- and every other consumer resolves a fixed version naturally within its own declared range: miniflare (exact-pinned by wrangler) pins 7.29.0 since the wrangler ^4.0.0 lift to 4.125.0, which retired the former miniflare/undici sibling entry; e2b's undici ^7.29.0 -> 7.29.0, node-gyp 12.4.0's ^6.25.0 -> 6.28.0, node-gyp 13's ^8.4.1 and jsdom 30's ^8.9.0 -> 8.9.0. Drop once dts-plugin depends on undici >=7.29.0. e2b's OPTIONAL ALIAS dependency undici8 (npm:undici@<exact>) needed its own alias-form entry while e2b 2.37.0 aliased it to 8.8.0, inside the >=8.0.0 <8.9.0 range above; the @e2b/code-interpreter ^2.6.0 lift to 2.7.1 brings e2b 2.45.0, whose alias is undici@8.10.0, so that entry was dropped. No sharp resolution remains for GHSA-f88m-g3jw-g9cj (sharp inherits four libvips CVEs: CVE-2026-33327/33328/35590/35591, vulnerable <0.35.0, fixed 0.35.0): the former next/sharp ^0.35.3 entry (next's copy ships in scanned images) was dropped once twenty-website's next ^16.2.6 lifted to 16.3.2, which pins sharp ^0.35.3 itself, with @react-email/ui's next forced onto that same 16.3.2 below -- twenty-sdk's direct sharp is bumped to ^0.35.3 in its own package.json and miniflare (0.35.2) is >=0.35.0 on its own; @argos-ci/storybook 6.2.3 (twenty-front + twenty-ui) includes the iframe-restoration fix and uses @argos-ci/core 6.7.2 with sharp ^0.35.3, so no argos sharp resolution is needed. The former 6.0.x pin avoided unhandled Monaco worker errors, but retained an iframe-sizing bug that produced oversized screenshots; Monaco workers are now initialized in twenty-front's Storybook preview. sharp 0.33.5 (favicons + @mintlify/prebuild, website/docs build tooling) sits in the advisory range but is not present in the scanned prod images (only 0.34.5 was flagged) and favicons caps sharp <0.34, so it is left to its parents. zapier-platform-core/form-data 4.0.6 -> CVE-2026-12143 / GHSA-hmw2-7cc7-3qxx (form-data CRLF injection via unescaped multipart field names and filenames, vulnerable >=4.0.0 <4.0.6); zapier-platform-core 19.0.0 hard-pins form-data 4.0.5 exact (no caret, still 4.0.5 in its latest) so no parent upgrade carries the fix; scoped to it as the sole 4.0.5 pinner -- every other form-data consumer resolves 4.0.6 naturally via its ^4.0.x range, so the pin dedupes onto it (nx was the other pinner until 22.7.7 moved it to 4.0.6, so its entry was dropped); drop once zapier-platform-core depends on form-data >=4.0.6. (the former @nestjs/platform-express/multer pin was dropped when the nest 11.2.x lockstep bump brought multer 2.2.0 through the parent.) (the former @nestjs/graphql/ws 8.21.0 pin for CVE-2026-48779 was dropped once @nestjs/graphql moved 13.4.2 -> 13.4.5, which pins ws 8.21.3 itself; twenty-server's resolver-scoping patch was rebased onto 13.4.5 for that lift.) @remote-dom/react/@types/react ^19.2.0 -> React type-identity dedup, SCOPED to @remote-dom/react only (every other package resolves @types/react 19 naturally from the workspace ^19.2.0 ranges). @remote-dom/react (transitive via twenty-front-component-renderer) lists @types/react ^18 in its own dependencies and nests its own copy; React 18 and 19 declare ReactNode differently (19 adds bigint + Promise<AwaitedReactNode>, drops ReactFragment's {}), so the two copies are mutually non-assignable and break twenty-front's typecheck (~156 TS2322 errors). Range-aligning our own packages can't fix a third-party's transitive @types pin, hence this single scoped override (only @types/react splits; runtime react/react-dom are peer-deps that converge naturally, and @types/react-dom does not nest a copy). Drop once @remote-dom/react widens @types/react to ^19 (latest 1.2.2 still pins ^18; tracked upstream in Shopify/remote-dom#153). graphql 16.8.1 -> singleton pin held below msw's ^16.12.0 dep and @nestjs/graphql's ^16.11.0 peer; drop after a validated repo-wide bump to latest 16.x; graphql-redis-subscriptions/ioredis 5.10.1 -> TS type-identity dedup: twenty-server passes its ioredis client into RedisPubSub, so this must equal the exact ioredis version pinned by twenty-server and bullmq (bump in lockstep); @types/qs 6.9.16 -> holdback below the 6.9.17 ParsedQs typing break (node-saml wants ^6.9.18); @opentelemetry/api 1.9.1 -> singleton guard for the NoopMeterProvider bug (#20231): ai 6.0.x pins 1.9.0 exact vs @sentry/node ^1.9.1, drop when workspace ai >=6.0.178 AND @scalar/agent-chat moves off ai 6.0.33; chokidar ^3 -> NestJS CLI watch needs fsevents on macOS, removed in chokidar 4/5 (#20316); tmp ^0.2.7 -> CVE, zapier-platform-cli 19 (latest) pins 0.2.5 and inquirer 7/8's external-editor wants ^0.0.33; (the former @mintlify/previewing/tar pin was dropped once the mintlify 4.2.816 lift brought a previewing that pins tar 7.5.21 itself.) @angular-devkit/core 19.2.24 -> picomatch CVE, blocked on @nestjs/cli >11.0.23 fixing the dist/src output regression (repo held at 11.0.16); yeoman-environment 6.0.1 -> CVE, zapier-platform-cli 19 (latest) pins 4.4.3; express/qs 6.15.2 -> qs CVE-2026-8723 / GHSA-q8mj-m7cp-5q26 (>=6.11.1 <=6.15.1, fixed 6.15.2) for old express 4.22.x pinned by @mintlify/previewing; the caret-range qs consumers all dedupe to 6.15.2 naturally (body-parser's entry was dropped once it resolved 1.20.6 whose qs ~6.15.1 reaches the fix on its own, and @cypress/request's once the verdaccio lift brought @cypress/request 4.0.1 whose qs ^6.15.2 does the same); drop once @mintlify/previewing moves off express 4.x; No postcss resolution remains for the postcss CVEs, latest GHSA-r28c-9q8g-f849 (path traversal in previous source map auto-loading via sourceMappingURL, arbitrary .map file disclosure, vulnerable <=8.5.17, fixed 8.5.18): next 16.3.2 pins 8.5.23 exact itself (the former next/postcss 8.5.23 entry went with the same next lift), the caret consumers (^8.4.38, ^8.4.47, ^8.5.15) dedupe onto 8.5.23 naturally, and @mintlify/common's entry was dropped once the mintlify 4.2.816 lift brought a common that pins 8.5.23 itself; No uuid resolution remains: googleapis-common 8.0.1 (forced via googleapis/googleapis-common) has no uuid dependency so googleapis-common/uuid was dropped, sockjs's entry went when sockjs left the tree and @cypress/request's when the verdaccio lift brought 4.0.1 which has no uuid dependency. @cyntler/react-doc-viewer/ajv 8.20.0 -> CVE, upstream (latest 1.17.1) pins ajv ^7 but never imports it, forcing v8 is safe; */esbuild 0.28.1 -> two esbuild advisories both fixed in 0.28.1: the Deno-module binary-integrity RCE GHSA-gv7w-rqvm-qjhr (vulnerable >=0.17.0 <0.28.1) and the earlier dev-server path-traversal GHSA-g7r4-m6w7-qqqr (Windows, >=0.27.3 <0.28.1). The Deno advisory's range covers every esbuild <0.28.1, so it re-exposed older transitive copies too. Preference is to fix by upgrading the parent, not by resolution -- done where it works: @size-limit/preset-small-lib+size-limit (now ^12.1.0, pin esbuild ^0.28.0) and wrangler (bumped within ^4.0.0 to 4.102.0, which pins esbuild 0.28.1) were bumped and resolve to 0.28.1 on their own, NO resolution needed. The three resolutions below are for parents that pin a vulnerable esbuild OUTSIDE the 0.28.1 range in their latest release: @opennextjs/aws exact-pins 0.25.4 (still 0.25.4 in latest 4.1.0); zapier-platform-cli exact-pins 0.25.8 (still 0.25.8 in latest 19.1.0); @lingui/cli 5.x pins ^0.25.1 -> caps <0.26 (6.x drops esbuild entirely but is a major migration). @react-email/ui (6.9.0 exact-pins 0.28.1), react-email (^0.28.0, no longer down-selected now that 0.28.1 has aged past the npmMinimalAgeGate) and storybook (10.4.6 widened its range to include ^0.28.0) resolve >=0.28.1 on their own, so their entries were dropped. tsx needs NO resolution: its ^4.x ranges resolve to 4.22.x which pins esbuild ~0.28.0 -> 0.28.1 on its own. (tsx had briefly been pinned to 4.21.0 because tsx 4.22's --import tsx/esm loader feeds esbuild-downleveled enums into jest's type-checking ts-node config compiler, yielding a spurious TS7022 in server-integration-test; that is now fixed at the source by dropping --import tsx/esm from the integration jest invocation in twenty-server project.json (it had been swept in by the Storybook 10 upgrade and is not needed there): ts-node alone now compiles the config + globalSetup, so there is no esbuild enum downleveling to trip TS7022 and decorator metadata is still emitted. tsx version is now irrelevant to the tests, so the pin was dropped.) Drop each entry once its parent ships a range that resolves to >=0.28.1 on its own. Our own twenty-client-sdk raises its esbuild floor to ^0.28.1 directly in its package.json instead of via a resolution. googleapis/googleapis-common 8.0.1 -> singleton dedup for the googleapis 173 upgrade. googleapis-common 8.0.2 (published 2026-06-04, AFTER googleapis 173 on 2026-05-28) regressed its google-auth-library dep from a range to exact 10.5.0 (and gaxios to exact 7.1.3), while googleapis itself pulls google-auth-library ^10.2.0 (10.7.0); the two mismatched copies make OAuth2Client's type-identity diverge between the client our provider builds (via googleapis -> 10.7.0) and the one gmail/calendar method options expect (via googleapis-common -> 10.5.0), breaking every gmail/calendar service typecheck (TS2322/TS2769). The parents are already at latest (googleapis 173.0.0, googleapis-common 8.0.2) so we cannot fix by upgrading; instead we pin googleapis' googleapis-common back to 8.0.1, the last version with RANGE deps (google-auth-library ^10.1.0, gaxios ^7.0.0-rc.4) -- and the version googleapis 173 originally shipped against. Ranges resolve to the same hoisted versions googleapis uses, so google-auth-library AND gaxios both collapse to a single copy with no further resolution (a global google-auth-library pin would only dedup one of the two). Scoped to googleapis since it is the sole googleapis-common 8.x consumer. Drop once googleapis-common 8.0.3+ restores range deps or googleapis bumps to a common that does. (the six @mintlify/*/js-yaml 4.3.1 pins for CVE-2026-53550 / GHSA-h67p-54hq-rp68, GHSA-52cp-r559-cp3m and GHSA-5p4m-2wfm-xmqj were dropped once the mintlify 4.2.816 lift brought a chain that pins js-yaml 4.3.1 itself; the cosmiconfig caret consumers dedupe onto it naturally.) Of the two js-yaml 3.x consumers (both declaring ^3.13.1): @istanbuljs/load-nyc-config@1.1.0 (via babel-plugin-istanbul coverage) is UNPINNED -- the 3.x line shipped backports for every js-yaml advisory (3.15.0 fixes GHSA-h67p-54hq-rp68 + GHSA-52cp-r559-cp3m, 3.15.1 fixes GHSA-5p4m-2wfm-xmqj), so it resolves a clean 3.15.1 within its own range, and as build-only coverage tooling that is enough. front-matter@4.0.2 (via mintlify in twenty-docs) stays FORCED to 4.3.1 (front-matter/js-yaml) as a deliberate posture call: 4.x is the maintained js-yaml line, while the 3.x fixes were backports to a legacy major that future advisories may not get, and front-matter parses docs content. Because js-yaml 4.x removed the safeLoad API front-matter's default path calls, the companion patch (front-matter@npm:4.0.2 -> .yarn/patches/front-matter-npm-4.0.2-e1cc0efa69.patch) sets loader = parser.load (safe-by-default in 4.x); pin and patch are a matched pair -- the patch without the pin would select 3.x's UNSAFE full-schema load, so they must only ever be dropped together. The version move stays a separate resolution because a yarn patch only rewrites a package's files, not its resolved dependency graph. Drop both once mintlify moves front-matter off js-yaml 3.x or drops it. @react-email/ui/next 16.3.2 -> Next.js July-2026 security release (CVE-2026-64641 App-Router Server-Actions DoS, CVE-2026-64645 rewrites/redirects SSRF + open redirect, and the sibling CVE-2026-64642..64648), vulnerable >=16.0.0 <16.2.11, fixed 16.2.11; @react-email/ui 6.9.0 hard-pins next 16.2.6 exact (transitive via react-email in twenty-emails). The parent bump was ATTEMPTED and reverted: @react-email/ui + react-email ^6.9.2 do carry next 16.3.0, but that pulls a SECOND next (16.3.0 alongside twenty-website's 16.3.2) plus its dependency subtree into the lockfile -- the scoped pin here forces @react-email/ui's next to 16.3.2, the version twenty-website already resolves within ^16.2.6, so it dedupes with ZERO new packages, which is the leaner outcome for a security PR. So @react-email/ui is held at ^6.9.0 with this scoped pin; drop once @react-email/ui itself depends on the next version twenty-website resolves. mintlify axios + adm-zip (twenty-docs) -> bumped mintlify ^4.2.594 -> ^4.2.790 (resolves 4.2.816), which pulls @mintlify/cli >=4.0.1393 -> adm-zip 0.6.0 (fixes CVE-2026-39244 / GHSA-xcpc-8h2w-3j85 for the @mintlify/cli + @mintlify/previewing copies) AND @mintlify/models >=0.0.347 -> axios 1.18.0 (fixes CVE-2026-44494 / SNYK-JS-AXIOS-17111079 axios prototype pollution via config.proxy, vulnerable >=1.15.2 <1.18.0). This one parent bump REPLACED three former scoped resolutions (@mintlify/models/axios, @mintlify/cli/adm-zip, @mintlify/previewing/adm-zip). Blast radius was measured and is contained: ~56 lockfile descriptors change, ALL inside twenty-docs' mintlify subtree (shiki/twoslash, remark/mdx, puppeteer 22->24, and a NESTED type-fest v5) -- the root-hoisted type-fest stays v4 (4.41.0) and every twenty-* workspace package declares type-fest 4.x, so type-fest v5 lives only inside mintlify's own nested tree and touches no workspace typecheck. All typechecks pass (twenty-front / -website / -emails / -ui / -shared reliably; twenty-server passes too modulo the pre-existing flaky tsgo 7.0.0-dev stack-overflow that hits ~1 run in 5 with ZERO type errors), and the mintlify CLI's harmless nested-React 'invalid hook call' warning is byte-identical before and after the bump. (The former nx/axios pin was likewise DROPPED -- nx on main is already 22.7.8, whose axios is 1.18.1, >=1.18.0 on its own.) adm-zip -> CVE-2026-39244 / GHSA-xcpc-8h2w-3j85 (adm-zip DoS: a crafted archive declaring a huge uncompressed size forces an unbounded Buffer.alloc up to 4GB before validation, vulnerable <0.6.0, fixed 0.6.0 -- the only fixed release, a major bump). The @mintlify/cli + @mintlify/previewing copies are fixed by the mintlify bump above; the remaining TWO consumers keep their OWN scoped pin to 0.6.0 (not a global one) because neither can be reached by a clean parent bump: zapier-platform-cli 19.0.0 pins 0.5.16 (still 0.5.16 in its latest 19.1.0 -- no fixed parent release, cf. its sibling zapier-platform-core/form-data + zapier-platform-cli/esbuild pins); @module-federation/dts-plugin 2.5.1 pins 0.5.10 (the fix lands in dts-plugin 2.8.1, but its parent @nx/module-federation 22.7.8 pins the module-federation stack at ^2.3.3 -> 2.5.1, so reaching it means forcing the whole build-critical module-federation runtime up or bumping all of nx to 23.x -- disproportionate, and it sits alongside the existing @module-federation/dts-plugin/undici pin for the same package and reason). adm-zip 0.6.0 is a MAJOR bump with two documented breaking changes (extractEntryTo now preserves subdirectories instead of flattening by basename; engines raised to Node >=14 -- both consumers already run Node >=18); validate the zapier CLI and the module-federation DTS build before merge. Drop the zapier pin once zapier-platform-cli ships adm-zip >=0.6.0; drop the dts-plugin pin once @nx/module-federation carries module-federation >=2.8.1.",
"version": "0.2.1",
"nx": {},
"scripts": {
"docs:generate": "tsx packages/twenty-docs/scripts/generate-docs-json.ts",
"docs:generate-navigation-template": "tsx packages/twenty-docs/scripts/generate-navigation-template.ts",
"docs:generate-paths": "tsx packages/twenty-docs/scripts/generate-documentation-paths.ts",
"docs:prune-orphans": "tsx packages/twenty-docs/scripts/prune-orphan-translations.ts",
"start": "npx concurrently --kill-others 'npx nx run-many -t start -p twenty-server twenty-front' 'npx wait-on tcp:3000 && npx nx run twenty-server:worker'"
},
"workspaces": {
"packages": [
"packages/twenty-front",
"packages/twenty-server",
"packages/twenty-emails",
"packages/twenty-ui",
"packages/twenty-utils",
"packages/twenty-zapier",
"packages/twenty-website",
"packages/twenty-docs",
"packages/twenty-e2e-testing",
"packages/twenty-shared",
"packages/twenty-sdk",
"packages/twenty-front-component-renderer",
"packages/twenty-client-sdk",
"packages/twenty-cli",
"packages/create-twenty-app",
"packages/twenty-codex-plugin",
"packages/twenty-oxlint-rules",
"packages/twenty-claude-skills"
]
},
"prettier": {
"singleQuote": true,
"trailingComma": "all",
"endOfLine": "lf"
}
}