{
  "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.16.0",
    "googleapis/googleapis-common": "8.0.1",
    "@cyntler/react-doc-viewer/ajv": "8.20.0",
    "front-matter/js-yaml": "4.3.2",
    "@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.5",
    "zapier-platform-cli/adm-zip": "0.6.0",
    "@module-federation/dts-plugin/adm-zip": "0.6.0",
    "@nestjs/platform-express/multer": "2.3.0",
    "nx/smol-toml": "1.7.1",
    "js-yaml@npm:4.3.1": "4.3.2",
    "sharp@npm:0.33.5": "0.35.4",
    "sharp@npm:^0.33.1": "0.35.4",
    "@mintlify/scraping/puppeteer": "25.10.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. sharp@npm:0.33.5 + sharp@npm:^0.33.1 -> 0.35.4 are the only sharp entries left for GHSA-f88m-g3jw-g9cj (sharp inherits four libvips CVEs: CVE-2026-33327/33328/35590/35591, vulnerable <0.35.0, fixed 0.35.0) nor for GHSA-rgj7-g3m4-5g8c (sharp <0.35.4 bundles libheif with GHSA-g89c-p67h-r497 / GHSA-2jg2-4ch7-h545, fixed 0.35.4): 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.x, which pins sharp ^0.35.3 itself, with @react-email/ui's next forced onto that same version below -- twenty-sdk's direct sharp is bumped to ^0.35.3 in its own package.json, every caret consumer resolves 0.35.4 within its own range, and miniflare's exact pin reached 0.35.4 through the wrangler ^4.0.0 lift to 4.131.x (a sharp@0.35.2 resolution was briefly considered for it and rejected in favour of that parent bump); @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 7.2.0 + @mintlify/prebuild, website/docs build tooling) sits in both advisory ranges; both parents are at their latest (@mintlify/prebuild 1.0.1255 still exact-pins favicons 7.2.0 and sharp 0.33.5) so no parent lift exists, and it is the last copy keeping Dependabot's root-lockfile sharp alert (#2077) open, so the two descriptors are forced to 0.35.4 -- the exact 0.33.5 pin and favicons' ^0.33.1 range, nothing else. Safe because favicons 7.3.1 itself moved to sharp ^0.35.3 with no API change on the calls favicons 7.2.0 makes; docs/website build only, never in the runtime images. Drop once @mintlify/prebuild pins sharp >=0.35.4 and a favicons that does the same. 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. @nestjs/platform-express/multer 2.3.0 -> three HIGH multer DoS advisories fixed in 2.3.0: GHSA-qfvm-cv95-jqjf / CVE-2026-77037 (file-descriptor leak on aborted uploads, =2.2.0), GHSA-wc9g-mqfw-jrwm / CVE-2026-77078 (crafted multipart field names) and GHSA-535w-7cp7-47q4 / CVE-2026-82333 (oversized array index in field names), both <2.3.0; @nestjs/platform-express exact-pins multer and every 11.x release up to the latest 11.2.4 still pins 2.2.0 -- only nest 12.x (12.0.2) moves to 2.3.0, and that is a lockstep major bump of the whole @nestjs/* stack, disproportionate for a patch-level multer fix. Re-added after a previous incarnation of this pin was dropped when the nest 11.2.x lockstep bump brought multer 2.2.0 through the parent; drop again once @nestjs/platform-express 11.x pins multer >=2.3.0 or the nest 12 lift lands. (nodemailer needs NO entry: twenty-server's own ^9.0.1 resolves 9.1.1, and imapflow -- which exact-pinned nodemailer 9.0.3 through its whole 1.x line -- was lifted to 2.0.2, which drops the nodemailer dependency (2.0.3, published 2026-09-14, is still inside the 3d npmMinimalAgeGate; take it on the next lift); the four September-2026 nodemailer advisories GHSA-2x7j-588g-ccc2 / GHSA-cc9r-2j5m-2m83 / GHSA-wmmp-3585-3rmp (fixed 9.1.0) and GHSA-8m3c-c648-2xjj (fixed 9.1.1) are therefore covered by the parent lift, not a pin.) @mintlify/scraping/puppeteer 25.10.0 -> two HIGH extract-zip advisories with NO patched release (extract-zip 2.0.1 is the last release, 2020): GHSA-jmr9-qjv8-65gv (unvalidated symlink path traversal) and GHSA-7pqw-9j4j-h8q3 / CVE-2026-19693. The only consumer is @puppeteer/browsers, which dropped extract-zip for modern-tar in its 3.x line; puppeteer >=25 carries @puppeteer/browsers 3.x, but @mintlify/scraping exact-pins puppeteer 24.3.1 and still does in its latest 4.0.1013, so no parent lift exists. Scoped to @mintlify/scraping (docs tooling, the sole puppeteer consumer in the tree); held at 25.10.0 because 25.11.0 (2026-09-14) is inside the 3d npmMinimalAgeGate. With this pin extract-zip leaves the lockfile entirely. Drop once @mintlify/scraping pins puppeteer >=25. nx/smol-toml 1.7.1 -> GHSA-7w5x-hrqm-74c2 / CVE-2026-85730 (HIGH, DoS via malformed TOML documents, vulnerable <=1.7.0, fixed 1.7.1); nx exact-pins smol-toml 1.6.1 and still does in its latest 23.2.1, so no parent upgrade carries the fix; scoped to nx (its sole consumer); drop once nx pins >=1.7.1. (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.16.0 -> two MEDIUM qs advisories fixed in 6.16.0: GHSA-4mjr-xmp4-gh2g / CVE-2026-82417 (DoS via attacker-controlled isBuffer, >=2.2.5 <6.16.0) and GHSA-x5fp-wj9c-mxmx / CVE-2026-82562 (array-limit bypass via bracket-key comma parsing, >=6.14.2 <=6.15.3; lifted from the 6.15.2 pin that covered CVE-2026-8723 / GHSA-q8mj-m7cp-5q26) for old express 4.22.x exact-pinned by @mintlify/previewing (4.22.0 / 4.22.2; its latest 4.0.1371 still pins 4.22.0, while express 4.22.3 itself moved to qs ~6.16.0, so the parent is the blocker); body-parser needs NO entry: the ~1.20.x consumers were lifted in-range to 1.20.8, whose qs ~6.16.0 reaches the fix on its own, and the caret-range qs consumers dedupe onto 6.16.0 naturally; drop once @mintlify/previewing moves off express 4.x or pins >=4.22.3; 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. js-yaml@npm:4.3.1 -> 4.3.2 -> GHSA-2883-xcg3-v3hh / CVE-2026-84375 (HIGH, maxTotalMergeKeys does not limit CPU use for empty merge sources, vulnerable >=4.0.0 <4.3.2, fixed 4.3.2; the 3.x line has its own 3.15.2 backport, which @istanbuljs/load-nyc-config's ^3.13.1 reaches on its own). The six @mintlify/* packages (cli, common, prebuild, previewing, scraping, validation) exact-pin js-yaml 4.3.1 and still do in the latest mintlify 4.2.892 / @mintlify/cli 4.0.1495, so no parent upgrade carries the fix; a single descriptor-keyed entry replaces six parent-scoped ones and touches only that exact 4.3.1 pin (every caret consumer dedupes onto 4.3.2 naturally). Their previous six pins had been dropped once the mintlify 4.2.816 lift brought a chain pinning 4.3.1 itself; drop once mintlify pins >=4.3.2. 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.2 (front-matter/js-yaml, lifted in step with the entry above) 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.5 -> 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 the version twenty-website already resolves within ^16.2.6 (16.3.5 since the September-2026 CRITICAL unauthenticated-RCE advisories GHSA-p293-qw3h-jr36 / CVE-2026-75604 on Windows-hosted servers and GHSA-2xp9-vwfh-vxw4 in the Image Optimization API with AVIF input, both >=16.0.0 <16.3.3, fixed 16.3.3), 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"
  }
}