mirror of
https://github.com/twentyhq/twenty.git
synced 2026-06-12 18:08:58 -04:00
2da28cb03e02f368b21ee2c4303a3f3e5b2ed821
259 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Charles Bochet
|
2da28cb03e |
security: upgrade express 4.22.2 + qs 6.15.2 resolution for dev-tool holdouts (Dependabot alert 1305) (#21434)
Closes the qs Dependabot alert — [1305](https://github.com/twentyhq/twenty/security/dependabot/1305) — by **upgrading express where possible** and using a **documented qs resolution** only for the irreducible dev-only holdouts. ### What's vulnerable `qs 6.14.x` (the `qs.stringify` DoS) is pulled by `express 4.22.1` / `body-parser 1.x`. The fix is `qs 6.15.2`, and there's **no backport to the 6.14 line**. ### Upgrade what we can (no resolution) `express 4.22.2` / `body-parser 1.20.5` moved to the patched `qs ~6.15.1`. So this PR bumps the app + in-range tooling to **express 4.22.2**: - twenty-server's stale direct pin `4.22.1 → 4.22.2` (its runtime HTTP is already express 5.2.1 via `@nestjs/platform-express`; this just patches the redundant direct dep — typecheck passes), - nx / electron-forge / webpack-dev-server / companion follow via `yarn up -R express body-parser`. ### Resolution only for the two holdouts Two **dev-only** tools pin express *exactly* with no patched release on a line we can use, so they still drag in `qs 6.14.2`: - **verdaccio** `4.22.1` — express 5 only landed in the **v7 beta** ([verdaccio#5680](https://github.com/verdaccio/verdaccio/issues/5680), [#2479](https://github.com/verdaccio/verdaccio/issues/2479)), **not** backported to the 6.x line we use. - **@mintlify/previewing** `4.22.0` — closed-source, latest still pins 4.22.0, no movement. A `qs: 6.15.2` resolution covers those, documented with a top-level `//resolutions` note and a removal trigger. ### Verification - `yarn install --immutable` ✓; every `qs` resolves to `6.15.2`; express app/tooling on `4.22.2` (only verdaccio/mintlify remain on old express, neutralized by the resolution). - `twenty-server` typecheck ✓ (90 files import express types; 4.22.1→4.22.2 is a patch). - Non-exploitable in prod regardless (express/body-parser use `qs.parse`, not the vulnerable `stringify`). |
||
|
Charles Bochet
|
9100fb1e9f |
security: scoped resolution for webpack-dev-server 5.2.4 (Dependabot alerts 1237/691/692) (#21420)
Closes 3 webpack-dev-server Dependabot alerts — [1237](https://github.com/twentyhq/twenty/security/dependabot/1237), [691](https://github.com/twentyhq/twenty/security/dependabot/691), [692](https://github.com/twentyhq/twenty/security/dependabot/692) — with a **scoped** resolution: `@electron-forge/plugin-webpack/webpack-dev-server: 5.2.4`. (These numbers are Dependabot **alert** IDs, not issue/PR numbers — written without `#` to avoid cross-linking unrelated issues, per review feedback.) ### Why a resolution (the one place it's unavoidable) webpack-dev-server is pulled **only** by `@electron-forge/plugin-webpack` (twenty-companion's build tooling), and **no electron-forge release uses webpack-dev-server 5** — not even `8.0.0-alpha.9` still pins `^4`. There is no parent-upgrade path, so a resolution is the only mechanism. ### Scoped, not global Per review feedback, the resolution targets `@electron-forge/plugin-webpack/webpack-dev-server` rather than a global override — it only forces v5 under electron-forge (the sole consumer), limiting blast radius. Verified the scoped syntax is honored: removing it reverts the lockfile to `webpack-dev-server@npm:^4.0.0`; with it, the lock pins `webpack-dev-server@npm:5.2.4` and `yarn install --immutable` passes. ### Why it's safe (constructor did NOT change v4→v5) `@electron-forge/plugin-webpack@7` calls `new WebpackDevServer(this.devServerOptions(), compiler)`. webpack-dev-server's constructor is `constructor(options, compiler)` in **both v4 and v5** (verified in `lib/Server.js:331` and `types/lib/Server.d.ts:1179`). The `(compiler, options)` → `(options, compiler)` swap happened at **v3 → v4**, not v4 → v5. The plugin passes only options unchanged in v5 (`hot`, `devMiddleware.writeToDisk`, `historyApiFallback`, `port`, `setupExitSignals`, `static`, `headers`) and uses none of the hooks v5 removed. ### Scope / verification - `yarn install --immutable` ✓; webpack-dev-server resolves to 5.2.4 only (was 4.15.2), no vulnerable copy remains. - Only exercised by `electron-forge start` (dev HMR); production `make`/`package` builds don't use it, and **twenty-companion has no CI workflow**, so this can't affect CI. - Residual manual check (not CI-covered): `yarn start:electron` in twenty-companion still boots the dev server. |
||
|
Charles Bochet
|
09cc0c6f21 |
security: clear yeoman-environment High alert via resolution to 6.0.1 (#21400)
## What
Clears the `yeoman-environment` High alert (GHSA-vv9j-gjw2-j8wp —
*arbitrary package install without confirmation*).
`yeoman-environment@4.4.3` is exact-pinned by `zapier-platform-cli`.
**There is no parent-bump fix**: `zapier-platform-cli@19.0.0` is the
latest stable and still pins 4.4.3 — cli 17→3.19.3, 18/19→4.4.3, all in
the vulnerable `< 6.0.1` range.
## Why a resolution (and why it's safe for us)
zapier-cli **lazy-loads** `yeoman-environment` via dynamic `import()`
*only* inside its `init` and `pull` scaffolding command handlers.
twenty-zapier only ever runs `validate` / `versions` / `push` /
`promote` (see `project.json`), so the vulnerable code path is never
imported here.
Since no zapier-cli release carries the fix, the only way to remove the
vulnerable version is a resolution:
```jsonc
"yeoman-environment": "6.0.1"
```
The 4→6 major only affects zapier-cli's `init`/`pull` (which we never
invoke); all our commands are unaffected.
## Verification
- `yeoman-environment` now **6.0.1** (no 4.4.3 in the lockfile)
- `nx build` + `typecheck` twenty-zapier ✅
- `zapier-platform validate` → **35/35 checks pass** with yeoman 6
forced
- `yarn install --immutable` clean
|
||
|
Charles Bochet
|
e53f877559 |
security: clear picomatch High alert via @angular-devkit/core resolution (#21398)
## What Clears the root `picomatch` High alert (GHSA-c2c7-rcm5-vvqj, range `>=4.0.0 <4.0.4`). `picomatch@4.0.2` is exact-pinned by `@angular-devkit/core@19.2.x`, pulled by NestJS's codegen tooling (`@nestjs/schematics` + `@nestjs/cli` use Angular's schematics engine). angular-devkit/core backported the picomatch 4.0.4 fix in **19.2.24**. ## Why a resolution here (not a parent bump) The clean parent-bump — bumping `@nestjs/cli` so it pulls patched angular-devkit — **breaks `nest build`**. `@nestjs/cli` 11.0.17+ has an SWC-builder output-path change: it writes compiled files under `dist/`**`src/`**`…` instead of `dist/…`, breaking every `node dist/<path>` reference (`main`, `command`, worker, `database/scripts/*`). This is what failed in the first revision of this PR (`Cannot find module '…/dist/database/scripts/truncate-db.js'`). - The cli's angular-devkit pin is **exact**, so there's no clean refresh. - Every `@nestjs/cli` ≥11.0.17 (incl. the latest 11.0.23) has the regression. - There's no stable NestJS 12/13 to move to (12 is alpha-only). - `tsconfig` `rootDir` doesn't override the output base. So a one-patch resolution is genuinely the cleaner, lower-risk fix: ```jsonc "@angular-devkit/core": "19.2.24" // patch within the same 19.2 minor ``` `@nestjs/cli` stays 11.0.16 (correct `dist/` layout), and picomatch resolves to 4.0.4. ## Verification - picomatch now **4.0.4 + 2.3.2** (both patched); no 4.0.2 in the lockfile - `nx build twenty-server` emits `dist/main.js` and `dist/database/scripts/*.js` at the correct paths (the prior CI failure) - `yarn install --immutable` clean |
||
|
Charles Bochet
|
3ee82c7a3c |
security: clear koa High alert by bumping nx 22.5.4 → 22.7.5 (#21396)
## What Clears the High `koa` alert (GHSA-7gcc-r8m5-44qm) — via a parent bump, **no resolution**. `koa@3.0.3` was a deep transitive of the module-federation build tooling: `koa` ← `@module-federation/dts-plugin@0.21.4` ← `@module-federation/enhanced@0.21.4`, pulled via **two** paths — `@nx/module-federation@22.5.4` (directly) and `@module-federation/node` (pinning the old `enhanced@0.21.x` line). `@module-federation/dts-plugin` 2.x dropped koa, so the fix moves both paths onto the 2.x line: - bump `nx` + `@nx/{jest,js,react,storybook,vite,web}` **22.5.4 → 22.7.5** (minor): `@nx/module-federation@22.7.5` uses `@module-federation/enhanced@^2.3.3` - refresh `@module-federation/node` within its existing `^2.7.21` range → 2.7.44, which uses `@module-federation/enhanced@2.5.1` Result: `@module-federation/enhanced` + `dts-plugin` collapse to 2.5.1, and **koa is gone from the tree entirely** (net −309 lockfile lines after dedup). ## Verification (nx is the monorepo task runner — verified broadly) - `nx build` + `typecheck`: twenty-shared, twenty-ui, twenty-front ✅ - `nx typecheck twenty-server` ✅ - `nx test twenty-shared` ✅ - `yarn install --immutable` clean The only `package.json` change is the nx version bump; everything else is lockfile. |
||
|
Charles Bochet
|
232ca8eec2 |
security: clear happy-dom High alerts by upgrading wyw-in-js 0.7 → 1.1 (#21394)
## What Clears the 2 High `happy-dom` alerts (GHSA-w4gp-fjgq-3q4g, GHSA-6q6h-j7hj-3r64) via a parent bump — **no resolution**. `happy-dom@15.11.7` came from **`@wyw-in-js/transform@0.7.0`** (Linaria's CSS transform), pinned by a root resolution + a local `.yarn` patch and requested by `@wyw-in-js/vite@^0.7.0` in twenty-front + twenty-ui-deprecated. - `@wyw-in-js/vite` `^0.7.0` → `^1.1.0` (twenty-front, twenty-ui-deprecated) - `@wyw-in-js/babel-preset` `^0.6.0` → `^1.1.0` (twenty-ui-deprecated) - **drop the `@wyw-in-js/transform` 0.7.0 resolutions + the `.yarn` patch** — the patch added a `visited` cycle-guard to `TransformCacheCollection.invalidateIfChanged`, which is **already upstream** in transform 1.1.0, so it's obsolete. `@wyw-in-js/transform` now resolves to **1.1.0** (→ happy-dom 20.10.2) and 0.8.1 (website, unchanged, → happy-dom 20.8.9). The vulnerable 0.7.0/15.11.7 are gone. ## Required config change wyw-in-js 1.x resolves modules in its CSS pre-build via vite's `resolve.alias` instead of `vite-tsconfig-paths`. So twenty-front's `@/` and `~/` tsconfig path aliases are mirrored into `vite.config` `resolve.alias` — otherwise the CSS evaluator throws `Cannot find module '@/...'` for aliased imports used inside `styled` definitions. ## Verification - happy-dom now **20.8.9 + 20.10.2** (both patched); no 15.x left - `nx build twenty-front` — CSS extraction works (**1018 files transformed**) + `typecheck` - `nx build twenty-ui`, `twenty-ui-deprecated` (Linaria CSS extraction) - website's Linaria transform runs fine (local build only stops on a missing `TWENTY_PARTNERS_API_URL` env var, unrelated) - `yarn install --immutable` clean |
||
|
Charles Bochet
|
1e309369bc |
chore(deps): upgrade tar to v7, evict vulnerable tar@6.2.1 (CVE-2026-24842) (#21341)
## Summary Removes all transitive **`tar@6.2.1`** from the dependency tree, resolving [Dependabot alert #400](https://github.com/twentyhq/twenty/security/dependabot/400) ([GHSA-34x7-hfp2-rc4v](https://github.com/isaacs/node-tar/security/advisories/GHSA-34x7-hfp2-rc4v) / CVE-2026-24842 — node-tar hardlink path traversal, high/8.2). The alert had been dismissed as `no_bandwidth`, but `tar@6.2.1` was still in the lockfile. I confirmed **6.2.1 is genuinely exploitable** by running the advisory's PoC (the hardlink escaped the extraction dir to a parent-directory file); `7.5.16` blocks it. There is **no patched 6.x release** — the fix only exists in `7.5.7+`. ## Approach Upgrade the build tooling that pulled tar v6 to the majors that depend on tar v7, rather than forcing tar onto v6-era consumers: | Package | Change | Mechanism | |---|---|---| | `node-gyp` | 10.2.0 / 7.1.2 / 9.4.1 → **12.4.0** | resolution | | `cacache` | 18 → **20.0.4** | resolution | | `make-fetch-happen` | → **15.0.6** | resolution | | `mintlify` (twenty-docs) | `latest` → **^4.2.594** (`@mintlify/previewing` → tar 7.5.15) | direct dep bump | | `@electron/rebuild`, `@electron/node-gyp`, `pacote` → `tar` | → **^7.5.16** | scoped resolution | The last row covers the two subtrees with **no upstream tar-v7 release**: `@electron/rebuild` (+ electron's `node-gyp` fork) in `twenty-companion`, and `pacote@11/15` via `zapier-platform-cli` in `twenty-zapier`. All `tar` now resolves to **7.5.13 / 7.5.15 / 7.5.16**; `node_modules` verified free of tar v6. ## Validation done - `yarn install` completes cleanly (constraints pass, only pre-existing `enableScripts: false` + peer-dep warnings). - Installed `node_modules` contains zero tar v6. ## Validation still needed before merge ⚠️ - The scoped overrides force tar v7 onto packages written for the v6 API. Resolution is consistent, but **runtime not exercised** (`enableScripts: false` skips native builds at install). Please validate: - `twenty-companion` electron `make` / native rebuild - `twenty-zapier` build/push - If either breaks, drop the scoped overrides and accept those two **dev/build-only** clusters as residual — they extract only trusted archives at build time, so the CVE (which needs attacker-controlled input) isn't reachable there. - `mintlify` is pinned (not `latest`) because `.yarnrc.yml`'s `npmMinimalAgeGate: 3d` quarantines the true latest. Pinning is arguably healthier, but it's a deliberate behavior change. ## Note twenty-server's own runtime tarball extraction (`extract-tarball-securely.util.ts`) was already on patched tar **and** rejects all hardlink/symlink entries — so this PR addresses the remaining build-tooling exposure, not a live runtime hole. Large `yarn.lock` churn is expected: the node-gyp/cacache major bumps refresh npm-internals tree-wide. |
||
|
Charles Bochet
|
822beb6a86 |
chore: force tmp >= 0.2.7 for root dev tooling (nx/zapier) (#21338)
Resolves the **root** `tmp` Dependabot alert (`tmp < 0.2.6`, #1308). In the root workspace, `tmp` is a transitive dep of `nx` (`~0.2.1`) and `zapier-platform-cli` (exact `0.2.1`) — dev/CLI tooling that **exact-pins old tmp with no fixed parent to upgrade to** (verified: even latest `zapier-platform-cli@15.19.0` still pins `0.2.1`). So it's pinned to the patched **0.2.7** via a root `resolutions` entry — the correct tool for un-dedupe-able transitive pins. Not in the prod image. ### Why the `twenty-apps/*` alerts are not fixed here Those come from a different source — `twenty-sdk → inquirer ^10 → @inquirer/editor 4.x → external-editor → tmp@0.0.33`. Rather than add a `resolutions` block to every app's `package.json` (which doesn't scale — every newly-scaffolded app would need it), they'll be fixed **centrally** by bumping `inquirer` in `twenty-sdk` (`^10 → ^12`, which reaches `@inquirer/editor 5.x` that dropped external-editor). Separate PR — apps inherit the fix on the next SDK release with no manual additions. |
||
|
Raphaël Bosi
|
c596a5e342 |
Rename twenty-ui to twenty-ui-deprecated and twenty-new-ui to twenty-ui to prepare package release (#21315)
## Description Promotes the next-gen UI library (formerly `twenty-new-ui`) to the name **`twenty-ui`** (v0.1.0, publishable) and renames the old package to **`twenty-ui-deprecated`**. Rewrites ~1,730 `twenty-ui` imports → `twenty-ui-deprecated`, updates all configs/CI/Docker/deps, and migrates twenty-front's `Toggle` to the new package (first consumer) as a drop-in. ## Next steps - Wire the `ui/v*` publish dispatch (`cd-deploy-tag.yaml` + `.yarnrc.yml`), then tag `ui/v0.1.0` to publish. - Continue migrating components from `twenty-ui-deprecated` → `twenty-ui`. |
||
|
Charles Bochet
|
d2e7dc0e74 |
security: bump vulnerable direct dependencies (axios, next, vitest, qs, dompurify, …) (#21309)
## What Within-major version bumps of **direct** dependencies to clear a large batch of Dependabot alerts that are breaching (or near) their SLA. No major-version changes — all stay within the current major, so risk is low. | Package | From → To | Clears | |---|---|---| | `axios` | ^1.13.5 → ^1.16.0 | ReDoS, Proxy-Auth leak, proto-pollution gadgets, NO_PROXY bypass, resource DoS (56 alerts) | | `next` | 16.1.7 → ^16.2.6 | DoS, middleware/proxy bypass, SSRF, cache poisoning, XSS (32 alerts) | | `vitest` | 4.0.18 → ^4.1.0 | **CRITICAL** — UI server arbitrary file read/exec (#1421) | | `qs` | ^6.11.2 → ^6.15.2 | `qs.stringify` DoS | | `dompurify` | 3.3.3 → ^3.4.0 | proto-pollution XSS + FORBID_TAGS / SAFE_FOR_TEMPLATES bypasses | | `@nestjs/core` | 11.1.16 → ^11.1.18 | improper output neutralization / injection | | `nodemailer` | 8.0.4 → 8.0.10 | SMTP command injection via CRLF (bumped via root `resolutions`) | | `path-to-regexp` | ^8.2.0 → ^8.4.0 | ReDoS via multiple wildcards | | `file-type` | ^21.3.1 → ^21.3.2 | ZIP decompression-bomb DoS | | `@opentelemetry/exporter-prometheus` | ^0.211.0 → ^0.217.0 | exporter process crash via malformed HTTP request (#1183/#1184) | ## Notes - Added a `next` root **resolution** so the dev-only `@react-email/preview-server` copy (hard-pinned at `16.0.10`) is also pulled up to the patched `16.2.x` line — otherwise that copy keeps the Next.js alerts open. - `@opentelemetry/exporter-prometheus` 0.217 pulled `@opentelemetry/sdk-metrics` to 2.7.1 (compatible); `@opentelemetry/api` stays pinned at 1.9.1. - **Transitive-only** vulnerable packages (undici, tmp, ws, brace-expansion, …) are handled in a **separate PR** per the split-by-group plan. - Breaking major bumps (electron, uuid, serialize-javascript) and migrations (Apollo Server 3→4, simplemde) are intentionally **out of scope** here. |
||
|
Raphaël Bosi
|
6f9b59b224 |
Scaffold twenty-new-ui (#21236)
Scaffolds `twenty-new-ui`, the next-gen replacement for `twenty-ui`, on **SCSS** Modules + **Base UI** (no Linaria). - **Tooling**: Vite lib build, subpaths mirror twenty-ui, typed SCSS Modules, Storybook + axe a11y, size-limit, Nx targets. - **Theme**: single token source → nx generateTheme emits the CSS vars + accessor; parity test asserts token-for-token match with twenty-ui. Migrated a first `Toggle` component with its stories to allow @charlesBochet to wire the new pixel-diff system. --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Thomas des Francs
|
1642be86f5 |
Bonapara/twenty codex plugin (#20857)
@martmull v2.0 ;) --------- Co-authored-by: martmull <martmull@hotmail.fr> Co-authored-by: bosiraphael <raphael.bosi@gmail.com> |
||
|
dependabot[bot]
|
6d550611d2 |
chore(deps): bump typescript from 5.9.2 to 5.9.3 (#20991)
Bumps [typescript](https://github.com/microsoft/TypeScript) from 5.9.2 to 5.9.3. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/microsoft/TypeScript/releases">typescript's releases</a>.</em></p> <blockquote> <h2>TypeScript 5.9.3</h2> <p>Note: this tag was recreated to point at the correct commit. The npm package contained the correct content.</p> <p>For release notes, check out the <a href="https://devblogs.microsoft.com/typescript/announcing-typescript-5-9/">release announcement</a></p> <ul> <li><a href="https://github.com/Microsoft/TypeScript/issues?utf8=%E2%9C%93&q=milestone%3A%22TypeScript+5.9.0%22+is%3Aclosed+">fixed issues query for Typescript 5.9.0 (Beta)</a>.</li> <li><a href="https://github.com/Microsoft/TypeScript/issues?utf8=%E2%9C%93&q=milestone%3A%22TypeScript+5.9.1%22+is%3Aclosed+">fixed issues query for Typescript 5.9.1 (RC)</a>.</li> <li><em>No specific changes for TypeScript 5.9.2 (Stable)</em></li> <li><a href="https://github.com/Microsoft/TypeScript/issues?utf8=%E2%9C%93&q=milestone%3A%22TypeScript+5.9.3%22+is%3Aclosed+">fixed issues query for Typescript 5.9.3 (Stable)</a>.</li> </ul> <p>Downloads are available on:</p> <ul> <li><a href="https://www.npmjs.com/package/typescript">npm</a></li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
neo773
|
323e66433e |
lint: migrate prettier to oxfmt (#20783)
Most changes are `implements` being unwrapped this is not a oxfmt regression Prettier in 3.7 (we're on 3.1) changed this behaviour prettier blog [post](https://prettier.io/blog/2025/11/27/3.7.0#change-18094) This unifies our linting tooling --------- Co-authored-by: github-actions <github-actions@twenty.com> Co-authored-by: Charles Bochet <charles@twenty.com> |
||
|
Félix Malfait
|
658bdf3e57 |
chore(website): rename twenty-website-new → twenty-website (#20745)
## Summary Follow-up to the Cloudflare/OpenNext migration (#20741). Now that the legacy `twenty-website` package was already removed in #20270, the `-new` suffix on the marketing site package is no longer meaningful. ## What changes - **Directory rename**: `git mv packages/twenty-website-new packages/twenty-website` (1213 files moved, no content change) - **Package + nx config**: `package.json` and `project.json` name fields updated, `sourceRoot` repointed - **Source refs**: `load-local-articles.ts` and `load-local-release-notes.ts` had a hardcoded `'twenty-website-new'` segment in their monorepo-root fallback path; `app/[locale]/releases/page.tsx` had display strings showing where to add content - **External refs**: root `package.json` workspaces, root `CLAUDE.md` / `README.md`, `twenty-sdk` + `create-twenty-app` READMEs, `.vscode/twenty.code-workspace`, `.cursor/rules/changelog-process.mdc`, Crowdin config + the three `website-i18n-*` CI workflows + `ci-website.yaml` - **Docker cleanup**: `packages/twenty-docker/twenty-website-new/Dockerfile` deleted; the two Makefile targets (`prod-website-new-build` / `prod-website-new-run`) that referenced it removed — EKS deploy was retired in the Cloudflare migration - **`yarn.lock`** regenerated against the new workspace path ## What's deliberately not in this PR The dev hostname `website-new.twenty-main.com` in `wrangler.jsonc` stays for now. Migrating it to `website.twenty-main.com` needs coordinated DNS deletion (current CNAME points at the legacy Docusaurus NLB and serves 503s) and removal of the matching legacy `website` Helm chart in `twenty-infra`. Flagged as a separate cleanup. Companion infra PR: https://github.com/twentyhq/twenty-infra/pull/682 (workflow paths + Terraform ECR + docs) ## Test plan - [x] `yarn install --immutable` resolves clean against the new path - [x] `npx nx typecheck twenty-website` passes - [x] `npx nx lint twenty-website` passes - [ ] CI on this PR confirms the same on a fresh checkout - [ ] After merge: trigger `Deploy Website` workflow against `environment=dev` to confirm the renamed working-directory deploys correctly |
||
|
Thomas des Francs
|
93d83b2e36 |
[codex] Add Twenty Claude skills package (#20450)
## Summary Adds a new `twenty-claude-skills` workspace package under `packages/` for Claude skills related to Twenty. ## Changes - Registers `packages/twenty-claude-skills` in the root Yarn workspace list. - Adds package metadata for `twenty-claude-skills`. - Adds a README documenting the multi-skill layout. - Adds the `twenty-record-presentation` skill under `skills/twenty-record-presentation/SKILL.md`. ## Impact This gives Claude-specific Twenty skills a dedicated package location while preserving the skill metadata from the provided skill bundle. ## Validation - Parsed the root `package.json` and `packages/twenty-claude-skills/package.json` with Node. - Compared the imported skill content against the source `.skill` archive; the only difference is a trailing newline at EOF. |
||
|
martmull
|
773245fa65 |
Isolate twenty apps from nx project (#20406)
- avoids importing twenty-shared or else in twenty-apps applications - update and add workflow action in twenty linear app |
||
|
neo773
|
1faf725498 |
Fix NestJS CLI pin chokidar to v3 (#20316)
fixes `EMFILE` by downgrading chokidar to v3 root cause is v4 removed kernel level FSEvents on macOS and instead uses `node:fs.watch` which doesn't scales for a repo of our size Seems to be working well, even survives multiple hot reloads after editing files |
||
|
Paul Rastoin
|
3b180e7cb5 |
Fix root monorepo package json focused installation (#20292)
# Introduction Running `yarn workspace focus twenty`( only installing root package.json dependencies ) would fail because the yarn constraint expect the yarn types to be installed |
||
|
Abdullah.
|
59107b5b23 | Remove twenty-website package. (#20270) | ||
|
martmull
|
3ffda0a29e |
Add twenty version validation (#20227)
as title, server version is checked before app deploy, and app install commands ### New section in publishing doc <img width="1344" height="912" alt="image" src="https://github.com/user-attachments/assets/2a9335e7-0a7a-4973-a2db-f30f03181001" /> --------- Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com> |
||
|
Charles Bochet
|
3c7c62c79f |
fix(server): deduplicate @opentelemetry/api to fix NoopMeterProvider (#20231)
## Summary **All OTel metrics in twenty-server have been silently dropped since April 30.** ### Root cause PR #20149 (`bump @sentry/profiling-node 10.27→10.51`) pulled in `@sentry/node@10.51.0`, which declares `@opentelemetry/api: ^1.9.1` as a **dependency** (not peer). Yarn installed it as a **nested** copy at `1.9.1`, while the hoisted copy stayed at `1.9.0`. At startup in `instrument.ts`: 1. `Sentry.init()` uses the **nested `1.9.1`** to register `trace`, `propagation`, `context` on the OTel global → global version becomes **`1.9.1`** 2. `setGlobalMeterProvider()` uses the **hoisted `1.9.0`** → `registerGlobal` sees version mismatch (`1.9.1` ≠ `1.9.0`) → **silently returns `false`** 3. Global stays `NoopMeterProvider` → every counter, gauge, and histogram in the server is a no-op ### What this PR does 1. **Reverts three troubleshooting PRs** that are no longer needed now that the root cause is identified: - #20230 — heartbeat gauge - #20228 — OTLP export lifecycle logs - #20221 — Sentry revert to 10.27 (which never actually downgraded in `yarn.lock` since `^10.27.0` resolved to `10.51.0`) 2. **Fixes the root cause**: - Root Yarn resolution pinning `@opentelemetry/api` to `1.9.1` → single copy in the entire tree, Sentry and Twenty share the same instance - Named import in `instrument.ts` (`import { metrics as otelMetrics }` instead of default import) as defense-in-depth against CJS interop issues ### Verified on dev cluster Exec'd into the running pod and confirmed: - `@sentry/node` nests `@opentelemetry/api@1.9.1`, hoisted is `1.9.0` - `Sentry.init()` → global version `1.9.1` → `setGlobalMeterProvider` with VERSION `1.9.0` → returns `false` → `NoopMeterProvider` - Same-version registration returns `true` → `MeterProvider` ✓ ## Test plan - [ ] CI passes (lint, typecheck, build) - [ ] Deploy to dev cluster and verify metrics flow to collector - [ ] Confirm `node_modules/@opentelemetry/api/package.json` shows `1.9.1` with no nested copy under `@sentry/` --------- Co-authored-by: Cursor <cursoragent@cursor.com> |
||
|
Paul Rastoin
|
8a0225e974 |
Dispatch root package.json hoisted deps and devDeps (#20140)
# Introduction Dispatching root package.json devDeps, prod deps Taking care of keeping non imported module used at build/ci level in the root package.json ## Motivation Avoid redundant deps declaration, better scoping allow better workspace deps granularity installation. <img width="385" height="247" alt="image" src="https://github.com/user-attachments/assets/9d7162ec-ba01-4f58-8563-38333733fdf0" /> --------- Co-authored-by: Charles Bochet <charles@twenty.com> |
||
|
dependabot[bot]
|
2c73d47555 |
Bump @storybook/react-vite from 10.2.13 to 10.3.3 (#19232)
Bumps [@storybook/react-vite](https://github.com/storybookjs/storybook/tree/HEAD/code/frameworks/react-vite) from 10.2.13 to 10.3.3. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/storybookjs/storybook/releases"><code>@storybook/react-vite</code>'s releases</a>.</em></p> <blockquote> <h2>v10.3.3</h2> <h2>10.3.3</h2> <ul> <li>Addon-Vitest: Streamline vite(st) config detection across init and postinstall - <a href="https://redirect.github.com/storybookjs/storybook/pull/34193">#34193</a>, thanks <a href="https://github.com/valentinpalkovic"><code>@valentinpalkovic</code></a>!</li> </ul> <h2>v10.3.2</h2> <h2>10.3.2</h2> <ul> <li>CLI: Shorten CTA link messages - <a href="https://redirect.github.com/storybookjs/storybook/pull/34236">#34236</a>, thanks <a href="https://github.com/shilman"><code>@shilman</code></a>!</li> <li>React Native Web: Fix vite8 support by bumping vite-plugin-rnw - <a href="https://redirect.github.com/storybookjs/storybook/pull/34231">#34231</a>, thanks <a href="https://github.com/dannyhw"><code>@dannyhw</code></a>!</li> </ul> <h2>v10.3.1</h2> <h2>10.3.1</h2> <ul> <li>CLI: Use npm info to fetch versions in repro command - <a href="https://redirect.github.com/storybookjs/storybook/pull/34214">#34214</a>, thanks <a href="https://github.com/yannbf"><code>@yannbf</code></a>!</li> <li>Core: Prevent story-local viewport from persisting in URL - <a href="https://redirect.github.com/storybookjs/storybook/pull/34153">#34153</a>, thanks <a href="https://github.com/ghengeveld"><code>@ghengeveld</code></a>!</li> </ul> <h2>v10.3.0</h2> <h2>10.3.0</h2> <p><em>> Improved developer experience, AI-assisting tools, and broader ecosystem support</em></p> <p>Storybook 10.3 contains hundreds of fixes and improvements including:</p> <ul> <li>🤖 Storybook MCP: Agentic component dev, docs, and test (Preview release for React)</li> <li>⚡ Vite 8 support</li> <li>▲ Next.js 16.2 support</li> <li>📝 ESLint 10 support</li> <li>〰️ Addon Pseudo-States: Tailwind v4 support</li> <li>🔧 Addon-Vitest: Simplified configuration - no more setup files required</li> <li>♿ Numerous accessibility improvements across the UI</li> </ul> <!-- raw HTML omitted --> <ul> <li>A11y: Add ScrollArea prop focusable for when it has static children - <a href="https://redirect.github.com/storybookjs/storybook/pull/33876">#33876</a>, thanks <a href="https://github.com/Sidnioulz"><code>@Sidnioulz</code></a>!</li> <li>A11y: Ensure popover dialogs have an ARIA label - <a href="https://redirect.github.com/storybookjs/storybook/pull/33500">#33500</a>, thanks <a href="https://github.com/gayanMatch"><code>@gayanMatch</code></a>!</li> <li>A11y: Make resize handles for addon panel and sidebar accessible <a href="https://redirect.github.com/storybookjs/storybook/pull/33980">#33980</a></li> <li>A11y: Underline MDX links for WCAG SC 1.4.1 compliance - <a href="https://redirect.github.com/storybookjs/storybook/pull/33139">#33139</a>, thanks <a href="https://github.com/NikhilChowdhury27"><code>@NikhilChowdhury27</code></a>!</li> <li>Actions: Add expandLevel parameter to configure tree depth - <a href="https://redirect.github.com/storybookjs/storybook/pull/33977">#33977</a>, thanks <a href="https://github.com/mixelburg"><code>@mixelburg</code></a>!</li> <li>Actions: Fix HandlerFunction type to support async callback props - <a href="https://redirect.github.com/storybookjs/storybook/pull/33864">#33864</a>, thanks <a href="https://github.com/mixelburg"><code>@mixelburg</code></a>!</li> <li>Addon-Docs: Add React as optimizeDeps entry - <a href="https://redirect.github.com/storybookjs/storybook/pull/34176">#34176</a>, thanks <a href="https://github.com/valentinpalkovic"><code>@valentinpalkovic</code></a>!</li> <li>Addon-Docs: Add support for `sourceState: 'none'` to canvas block parameters - <a href="https://redirect.github.com/storybookjs/storybook/pull/33627">#33627</a>, thanks <a href="https://github.com/quisido"><code>@quisido</code></a>!</li> <li>Addon-docs: Restore `docs.components` overrides for doc blocks <a href="https://redirect.github.com/storybookjs/storybook/pull/34111">#34111</a></li> <li>Addon-Vitest: Add channel API to programmatically trigger test runs - <a href="https://redirect.github.com/storybookjs/storybook/pull/33206">#33206</a>, thanks <a href="https://github.com/JReinhold"><code>@JReinhold</code></a>!</li> <li>Addon-Vitest: Handle additional vitest config export patterns in postinstall - <a href="https://redirect.github.com/storybookjs/storybook/pull/34106">#34106</a>, thanks <a href="https://github.com/copilot-swe-agent"><code>@copilot-swe-agent</code></a>!</li> <li>Addon-Vitest: Make Playwright `--with-deps` platform-aware to avoid `sudo` prompt on Linux <a href="https://redirect.github.com/storybookjs/storybook/pull/34121">#34121</a></li> <li>Addon-Vitest: Refactor Vitest setup to eliminate the need for a dedicated setup file - <a href="https://redirect.github.com/storybookjs/storybook/pull/34025">#34025</a>, thanks <a href="https://github.com/valentinpalkovic"><code>@valentinpalkovic</code></a>!</li> <li>Addon-Vitest: Support Vitest canaries - <a href="https://redirect.github.com/storybookjs/storybook/pull/33833">#33833</a>, thanks <a href="https://github.com/valentinpalkovic"><code>@valentinpalkovic</code></a>!</li> <li>Angular: Add moduleResolution: bundler to tsconfig - <a href="https://redirect.github.com/storybookjs/storybook/pull/34085">#34085</a>, thanks <a href="https://github.com/valentinpalkovic"><code>@valentinpalkovic</code></a>!</li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/storybookjs/storybook/blob/next/CHANGELOG.md"><code>@storybook/react-vite</code>'s changelog</a>.</em></p> <blockquote> <h2>10.3.3</h2> <ul> <li>Addon-Vitest: Streamline vite(st) config detection across init and postinstall - <a href="https://redirect.github.com/storybookjs/storybook/pull/34193">#34193</a>, thanks <a href="https://github.com/valentinpalkovic"><code>@valentinpalkovic</code></a>!</li> </ul> <h2>10.3.2</h2> <ul> <li>CLI: Shorten CTA link messages - <a href="https://redirect.github.com/storybookjs/storybook/pull/34236">#34236</a>, thanks <a href="https://github.com/shilman"><code>@shilman</code></a>!</li> <li>React Native Web: Fix vite8 support by bumping vite-plugin-rnw - <a href="https://redirect.github.com/storybookjs/storybook/pull/34231">#34231</a>, thanks <a href="https://github.com/dannyhw"><code>@dannyhw</code></a>!</li> </ul> <h2>10.3.1</h2> <ul> <li>CLI: Use npm info to fetch versions in repro command - <a href="https://redirect.github.com/storybookjs/storybook/pull/34214">#34214</a>, thanks <a href="https://github.com/yannbf"><code>@yannbf</code></a>!</li> <li>Core: Prevent story-local viewport from persisting in URL - <a href="https://redirect.github.com/storybookjs/storybook/pull/34153">#34153</a>, thanks <a href="https://github.com/ghengeveld"><code>@ghengeveld</code></a>!</li> </ul> <h2>10.3.0</h2> <p><em>> Improved developer experience, AI-assisting tools, and broader ecosystem support</em></p> <p>Storybook 10.3 contains hundreds of fixes and improvements including:</p> <ul> <li>🤖 Storybook MCP: Agentic component dev, docs, and test (Preview release for React)</li> <li>⚡ Vite 8 support</li> <li>▲ Next.js 16.2 support</li> <li>📝 ESLint 10 support</li> <li>〰️ Addon Pseudo-States: Tailwind v4 support</li> <li>🔧 Addon-Vitest: Simplified configuration - no more setup files required</li> <li>♿ Numerous accessibility improvements across the UI</li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
Gabriel
|
36dece43c7 |
Fix: Upgrade Nodemailer to address SMTP command injection vulnerability (#19151)
📄 Summary This PR upgrades the nodemailer dependency to a secure version (≥ 8.0.4) to fix a known SMTP command injection vulnerability (GHSA-c7w3-x93f-qmm8). 🚨 Issue The current version used in twenty-server (^7.0.11, resolved to 7.0.11 / 7.0.13) is vulnerable to SMTP command injection due to improper sanitization of the envelope.size parameter. This could allow CRLF injection, potentially enabling attackers to add unauthorized recipients to outgoing emails. 🔍 Root Cause The vulnerability originates from insufficient validation of user-controlled input in the SMTP envelope, specifically the size field, which can be exploited via crafted input containing CRLF sequences. ✅ Changes Upgraded nodemailer to version ^8.0.4 Ensured compatibility with existing email sending logic Verified that no breaking changes affect current usage 🔐 Security Impact This update mitigates the risk of: SMTP command injection Unauthorized email recipient manipulation Potential data leakage via crafted email payloads 📎 References GHSA: GHSA-c7w3-x93f-qmm8 CVE: (see linked report in issue) --------- Co-authored-by: Félix Malfait <felix.malfait@gmail.com> Co-authored-by: Charles Bochet <charlesBochet@users.noreply.github.com> |
||
|
Paul Rastoin
|
37908114fc |
[SDK] Extract twenty-front-component-renderer outside of twenty-sdk ( 2.8MB ) (#19021)
Followup https://github.com/twentyhq/twenty/pull/19010 ## Dependency diagram ``` ┌─────────────────────┐ │ twenty-front │ │ (React frontend) │ └─────────┬───────────┘ │ imports runtime: │ FrontComponentRenderer │ FrontComponentRendererWithSdkClient │ useFrontComponentExecutionContext ▼ ┌──────────────────────────────────┐ ┌─────────────────────────┐ │ twenty-front-component-renderer │────────▶│ twenty-sdk │ │ (remote-dom host + worker) │ │ (app developer SDK) │ │ │ │ │ │ imports from twenty-sdk: │ │ Public API: │ │ • types only: │ │ defineFrontComponent │ │ FrontComponentExecutionContext│ │ navigate, closeSide… │ │ NavigateFunction │ │ useFrontComponent… │ │ CloseSidePanelFunction │ │ Command components │ │ CommandConfirmation… │ │ conditional avail. │ │ OpenCommandConfirmation… │ │ │ │ EnqueueSnackbarFunction │ │ Internal only: │ │ etc. │ │ frontComponentHost… │ │ │ │ front-component-build │ │ owns locally: │ │ esbuild plugins │ │ • ALLOWED_HTML_ELEMENTS │ │ │ │ • EVENT_TO_REACT │ └────────────┬────────────┘ │ • HTML_TAG_TO_CUSTOM_ELEMENT… │ │ │ • SerializedEventData │ │ types │ • PropertySchema │ ▼ │ • frontComponentHostComm… │ ┌─────────────────────────┐ │ (local ref to globalThis) │ │ twenty-shared │ │ • setFrontComponentExecution… │ │ (common types/utils) │ │ (local impl, same keys) │ │ AppPath, SidePanelP… │ │ │ │ EnqueueSnackbarParams │ └──────────────────────────────────┘ │ isDefined, … │ │ └─────────────────────────┘ │ also depends on ▼ twenty-shared (types) @remote-dom/* (runtime) @quilted/threads (runtime) react (runtime) ``` **Key points:** - **`twenty-front`** depends on the renderer, **not** on `twenty-sdk` directly (for rendering) - **`twenty-front-component-renderer`** depends on `twenty-sdk` for **types only** (function signatures, `FrontComponentExecutionContext`). The runtime bridge (`frontComponentHostCommunicationApi`) is shared via `globalThis` keys, not module imports - **`twenty-sdk`** has no dependency on the renderer — clean one-way dependency - The renderer owns all remote-dom infrastructure (element schemas, event mappings, custom element tags) that was previously leaking through the SDK's public API - The SDK's `./build` entry point was removed entirely (unused) |
||
|
Abdullah.
|
22c9693ce5 |
First PR to bring in the new twenty website. (#19035)
This PR contains Menu, Hero, TrustedBy, Problem, ThreeCards and Footer sections of the new website. Most components in there match the Figma designs, except for two things. - Zoom levels on 3D illustrations from Endless Tools. - Menu needs to have the same color as Hero - it's not happening at the moment since Menu is in the layout, not nested inside pages or Hero. Images are placeholders (same as Figma). |
||
|
Paul Rastoin
|
052aecccc7 |
Refactor dependency graph for SDK, client-sdk and create-app (#18963)
## Summary
### Externalize `twenty-client-sdk` from `twenty-sdk`
Previously, `twenty-client-sdk` was listed as a `devDependency` of
`twenty-sdk`, which caused Vite to bundle it inline into the dist
output. This meant end-user apps had two copies of `twenty-client-sdk`:
one hidden inside `twenty-sdk`'s bundle, and one installed explicitly in
their `node_modules`. These copies could drift apart since they weren't
guaranteed to be the same version.
**Change:** Moved `twenty-client-sdk` from `devDependencies` to
`dependencies` in `twenty-sdk/package.json`. Vite's `external` function
now recognizes it and keeps it as an external `require`/`import` in the
dist output. End users get a single deduplicated copy resolved by their
package manager.
### Externalize `twenty-sdk` from `create-twenty-app`
Similarly, `create-twenty-app` had `twenty-sdk` as a `devDependency`
(bundled inline). After refactoring `create-twenty-app` to
programmatically import operations from `twenty-sdk` (instead of
shelling out via `execSync`), it became a proper runtime dependency.
**Change:** Moved `twenty-sdk` from `devDependencies` to `dependencies`
in `create-twenty-app/package.json`.
### Switch E2E CI to `yarn npm publish`
The `workspace:*` protocol in `dependencies` is a Yarn-specific feature.
`npm publish` publishes it as-is (which breaks for consumers), while
`yarn npm publish` automatically replaces `workspace:*` with the
resolved version at publish time (e.g., `workspace:*` becomes `=1.2.3`).
**Change:** Replaced `npm publish` with `yarn npm publish` in
`.github/workflows/ci-create-app-e2e.yaml`.
### Replace `execSync` with programmatic SDK calls in
`create-twenty-app`
`create-twenty-app` was shelling out to `yarn twenty remote add` and
`yarn twenty server start` via `execSync`, which assumed the `twenty`
binary was already installed in the scaffolded app. This was fragile and
created an implicit circular dependency.
**Changes:**
- Replaced `execSync('yarn twenty remote add ...')` with a direct call
to `authLoginOAuth()` from `twenty-sdk/cli`
- Replaced `execSync('yarn twenty server start')` with a direct call to
`serverStart()` from `twenty-sdk/cli`
- Deleted the duplicated `setup-local-instance.ts` from
`create-twenty-app`
### Centralize `serverStart` as a dedicated operation
The Docker server start logic was previously inline in the `server
start` CLI command handler (`server.ts`), and `setup-local-instance.ts`
was shelling out to `yarn twenty server start` to invoke it -- meaning
`twenty-sdk` was calling itself via a child process.
**Changes:**
- Extracted the Docker container management logic into a new
`serverStart` operation (`cli/operations/server-start.ts`)
- Merged the detect-or-start flow from `setup-local-instance.ts` into
`serverStart` (detect across multiple ports, start Docker if needed,
poll for health)
- Deleted `setup-local-instance.ts` from `twenty-sdk`
- Added `onProgress` callback (consistent with other operations like
`appBuild`) instead of direct `console.log` calls
- Both the `server start` CLI command and `create-twenty-app` now call
`serverStart()` programmatically
related to https://github.com/twentyhq/twenty-infra/pull/525
|
||
|
Charles Bochet
|
790a58945b |
Migrate twenty-companion from npm to yarn workspaces (#18946)
## Summary - Migrates twenty-companion from standalone npm to the repo yarn workspaces - Removes package-lock.json (resolves Oneleet security finding about npm lifecycle scripts) - Converts npm overrides to yarn resolutions - Updates scripts from npm run to yarn ## Test plan - [x] Verified yarn install succeeds at root - [x] Verified yarn start in twenty-companion launches the Electron app - [ ] Verify Oneleet finding is resolved after merge |
||
|
Paul Rastoin
|
4ea2e32366 |
Refactor twenty client sdk provisioning for logic function and front-component (#18544)
## 1. The `twenty-client-sdk` Package (Source of Truth)
The monorepo package at `packages/twenty-client-sdk` ships with:
- A **pre-built metadata client** (static, generated from a fixed
schema)
- A **stub core client** that throws at runtime (`CoreApiClient was not
generated...`)
- Both ESM (`.mjs`) and CJS (`.cjs`) bundles in `dist/`
- A `package.json` with proper `exports` map for
`twenty-client-sdk/core`, `twenty-client-sdk/metadata`, and
`twenty-client-sdk/generate`
## 2. Generation & Upload (Server-Side, at Migration Time)
**When**: `WorkspaceMigrationRunnerService.run()` executes after a
metadata schema change.
**What happens in `SdkClientGenerationService.generateAndStore()`**:
1. Copies the stub `twenty-client-sdk` package from the server's assets
(resolved via `SDK_CLIENT_PACKAGE_DIRNAME` — from
`dist/assets/twenty-client-sdk/` in production, or from `node_modules`
in dev)
2. Filters out `node_modules/` and `src/` during copy — only
`package.json` + `dist/` are kept (like an npm publish)
3. Calls `replaceCoreClient()` which uses `@genql/cli` to introspect the
**application-scoped** GraphQL schema and generates a real
`CoreApiClient`, then compiles it to ESM+CJS and overwrites
`dist/core.mjs` and `dist/core.cjs`
4. Archives the **entire package** (with `package.json` + `dist/`) into
`twenty-client-sdk.zip`
5. Uploads the single archive to S3 under
`FileFolder.GeneratedSdkClient`
6. Sets `isSdkLayerStale = true` on the `ApplicationEntity` in the
database
## 3. Invalidation Signal
The `isSdkLayerStale` boolean column on `ApplicationEntity` is the
invalidation mechanism:
- **Set to `true`** by `generateAndStore()` after uploading a new client
archive
- **Checked** by both logic function drivers before execution — if
`true`, they rebuild their local layer
- **Set back to `false`** by `markSdkLayerFresh()` after the driver has
successfully consumed the new archive
Default is `false` so existing applications without a generated client
aren't affected.
## 4a. Logic Functions — Local Driver
**`ensureSdkLayer()`** is called before every execution:
1. Checks if the local SDK layer directory exists AND `isSdkLayerStale`
is `false` → early return
2. Otherwise, cleans the local layer directory
3. Calls `downloadAndExtractToPackage()` which streams the zip from S3
directly to disk and extracts the full package into
`<tmpdir>/sdk/<workspaceId>-<appId>/node_modules/twenty-client-sdk/`
4. Calls `markSdkLayerFresh()` to set `isSdkLayerStale = false`
**At execution time**, `assembleNodeModules()` symlinks everything from
the deps layer's `node_modules/` **except** `twenty-client-sdk`, which
is symlinked from the SDK layer instead. This ensures the logic
function's `import ... from 'twenty-client-sdk/core'` resolves to the
generated client.
## 4b. Logic Functions — Lambda Driver
**`ensureSdkLayer()`** is called during `build()`:
1. Checks if `isSdkLayerStale` is `false` and an existing Lambda layer
ARN exists → early return
2. Otherwise, deletes all existing layer versions for this SDK layer
name
3. Calls `downloadArchiveBuffer()` to get the raw zip from S3 (no disk
extraction)
4. Calls `reprefixZipEntries()` which streams the zip entries into a
**new zip** with the path prefix
`nodejs/node_modules/twenty-client-sdk/` — this is the Lambda layer
convention path. All done in memory, no disk round-trip
5. Publishes the re-prefixed zip as a new Lambda layer via
`publishLayer()`
6. Calls `markSdkLayerFresh()`
**At function creation**, the Lambda is created with **two layers**:
`[depsLayerArn, sdkLayerArn]`. The SDK layer is listed last so it
overwrites the stub `twenty-client-sdk` from the deps layer (later
layers take precedence in Lambda's `/opt` merge).
## 5. Front Components
Front components are built by `app:build` with `twenty-client-sdk/core`
and `twenty-client-sdk/metadata` as **esbuild externals**. The stored
`.mjs` in S3 has unresolved bare import specifiers like `import {
CoreApiClient } from 'twenty-client-sdk/core'`.
SDK import resolution is split between the **frontend host** (fetching &
caching SDK modules) and the **Web Worker** (rewriting imports):
**Server endpoints**:
- `GET /rest/front-components/:id` —
`FrontComponentService.getBuiltComponentStream()` returns the **raw
`.mjs`** directly from file storage. No bundling, no SDK injection.
- `GET /rest/sdk-client/:applicationId/:moduleName` —
`SdkClientController` reads a single file (e.g. `dist/core.mjs`) from
the generated SDK archive via
`SdkClientGenerationService.readFileFromArchive()` and serves it as
JavaScript.
**Frontend host** (`FrontComponentRenderer` in `twenty-front`):
1. Queries `FindOneFrontComponent` which returns `applicationId`,
`builtComponentChecksum`, `usesSdkClient`, and `applicationTokenPair`
2. If `usesSdkClient` is `true`, renders
`FrontComponentRendererWithSdkClient` which calls the
`useApplicationSdkClient` hook
3. `useApplicationSdkClient({ applicationId, accessToken })` checks the
Jotai atom family cache for existing blob URLs. On cache miss, fetches
both SDK modules from `GET /rest/sdk-client/:applicationId/core` and
`/metadata`, creates **blob URLs** for each, and stores them in the atom
family
4. Once the blob URLs are cached, passes them as `sdkClientUrls`
(already blob URLs, not server URLs) to `SharedFrontComponentRenderer` →
`FrontComponentWorkerEffect` → worker's `render()` call via
`HostToWorkerRenderContext`
**Worker** (`remote-worker.ts` in `twenty-sdk`):
1. Fetches the raw component `.mjs` source as text
2. If `sdkClientUrls` are provided and the source contains SDK import
specifiers (`twenty-client-sdk/core`, `twenty-client-sdk/metadata`),
**rewrites** the bare specifiers to the blob URLs received from the host
(e.g. `'twenty-client-sdk/core'` → `'blob:...'`)
3. Creates a blob URL for the rewritten source and `import()`s it
4. Revokes only the component blob URL after the module is loaded — the
SDK blob URLs are owned and managed by the host's Jotai cache
This approach eliminates server-side esbuild bundling on every request,
caches SDK modules per application in the frontend, and keeps the
worker's job to a simple string rewrite.
## Summary Diagram
```
app:build (SDK)
└─ twenty-client-sdk stub (metadata=real, core=stub)
│
▼
WorkspaceMigrationRunnerService.run()
└─ SdkClientGenerationService.generateAndStore()
├─ Copy stub package (package.json + dist/)
├─ replaceCoreClient() → regenerate core.mjs/core.cjs
├─ Zip entire package → upload to S3
└─ Set isSdkLayerStale = true
│
┌────────┴────────────────────┐
▼ ▼
Logic Functions Front Components
│ │
├─ Local Driver ├─ GET /rest/sdk-client/:appId/core
│ └─ downloadAndExtract │ → core.mjs from archive
│ → symlink into │
│ node_modules ├─ Host (useApplicationSdkClient)
│ │ ├─ Fetch SDK modules
└─ Lambda Driver │ ├─ Create blob URLs
└─ downloadArchiveBuffer │ └─ Cache in Jotai atom family
→ reprefixZipEntries │
→ publish as Lambda ├─ GET /rest/front-components/:id
layer │ → raw .mjs (no bundling)
│
└─ Worker (browser)
├─ Fetch component .mjs
├─ Rewrite imports → blob URLs
└─ import() rewritten source
```
## Next PR
- Estimate perf improvement by implementing a redis caching for front
component client storage ( we don't even cache front comp initially )
- Implem frontent blob invalidation sse event from server
---------
Co-authored-by: Charles Bochet <charlesBochet@users.noreply.github.com>
|
||
|
Félix Malfait
|
b470cb21a1 |
Upgrade Apollo Client to v4 and refactor error handling (#18584)
## Summary This PR upgrades Apollo Client from v3.10.0 to v4 and refactors error handling patterns across the codebase to use a new centralized `useSnackBarOnQueryError` hook. ## Key Changes - **Dependency Update**: Upgraded `@apollo/client` from `^3.10.0` to `^3.11.0` in root package.json - **New Hook**: Added `useSnackBarOnQueryError` hook for centralized Apollo query error handling with snack bar notifications - **Error Handling Refactor**: Updated 100+ files to use the new error handling pattern: - Removed direct `ApolloError` imports where no longer needed - Replaced manual error handling logic with `useSnackBarOnQueryError` hook - Simplified error handling in hooks and components across multiple modules - **GraphQL Codegen**: Updated codegen configuration files to work with Apollo Client v3.11.0 - **Type Definitions**: Added TypeScript declaration file for `apollo-upload-client` module - **Test Updates**: Updated test files to reflect new error handling patterns ## Notable Implementation Details - The new `useSnackBarOnQueryError` hook provides a consistent way to handle Apollo query errors with automatic snack bar notifications - Changes span across multiple feature areas: auth, object records, settings, workflows, billing, and more - All changes maintain backward compatibility while improving code maintainability and reducing duplication - Jest configuration updated to work with the new Apollo Client version https://claude.ai/code/session_019WGZ6Rd7sEHuBg9sTrXRqJ --------- Co-authored-by: Claude <noreply@anthropic.com> |
||
|
Raphaël Bosi
|
c9deab4373 |
[COMMAND MENU ITEMS] Remove standard front components (#18581)
All standard command menu items will link to an engine component instead of standard front components. |
||
|
Paul Rastoin
|
b699619756 |
Create twenty app e2e test ci (#18497)
# Introduction Verifies whole following flow: - Create and sdk app build and publication - Global create-twenty-app installation - Creating an app - installing app dependencies - auth:login - app:build - function:execute - Running successfully auto-generated integration tests ## Create twenty app options refactor Allow having a flow that do not require any prompt |
||
|
Raphaël Bosi
|
2de022afcf |
Add standard command menu items (#18527)
## Add standard command menu items
### Summary
This PR introduces standard command menu items, migrating hardcoded
command menu actions to the backend command menu item architecture
powered by front components. It adds a new `twenty-standard-application`
package that defines, builds, and registers front components as standard
command menu items, gated behind the `IS_COMMAND_MENU_ITEM_ENABLED`
feature flag.
### Description
- **New `twenty-standard-application` package**: Contains front
component definitions with an esbuild-based build pipeline that
generates minified `.mjs` bundles and a manifest with checksums.
- **Server-side registration**: New constants register all items with
metadata (labels, icons, positions, availability types, conditional
expressions). A `StandardFrontComponentUploadService` uploads built
components to file storage.
- **`FALLBACK` availability type**: New enum value for command menu
items that appear as fallback options (e.g., "Search Records" fallback).
- **`CommandMenuContextApi` refactor**
- **Conditional availability enhancements**: New array-based helper
functions for evaluating multi-record conditions.
- **Frontend wiring** (twenty-front):
`useCommandMenuItemFrontComponentCommands`
## Next steps
Only simple commands have been implemented for now:
- **Navigation (9)** -- `CommandLink`: go-to-companies,
go-to-dashboards, go-to-notes, go-to-opportunities, go-to-people,
go-to-runs, go-to-settings, go-to-tasks, go-to-workflows
- **Side panel (4)** -- `CommandOpenSidePanelPage`: ask-ai,
search-records, search-records-fallback, view-previous-ai-chats
We still have to implement front components for all the following
commands:
All have placeholder `execute` logic (`async () => {}`) with a `// TODO:
implement execute logic` comment:
**Record (22)**
- `add-to-favorites`, `remove-from-favorites`
- `create-new-record`, `create-new-view`
- `delete-single-record`, `delete-multiple-records`
- `destroy-single-record`, `destroy-multiple-records`
- `restore-single-record`, `restore-multiple-records`
- `export-from-record-index`, `export-from-record-show`,
`export-multiple-records`, `export-note-to-pdf`, `export-view`
- `hide-deleted-records`, `see-deleted-records`
- `import-records`, `merge-multiple-records`, `update-multiple-records`
- `navigate-to-next-record`, `navigate-to-previous-record`
**Page layout (3)** -- `cancel-record-page-layout`,
`edit-record-page-layout`, `save-record-page-layout`
**Dashboard (4)** -- `cancel-dashboard-layout`, `duplicate-dashboard`,
`edit-dashboard-layout`, `save-dashboard-layout`
**Workflow (10)** -- `activate-workflow`, `add-node-workflow`,
`deactivate-workflow`, `discard-draft-workflow`, `duplicate-workflow`,
`see-active-version-workflow`, `see-runs-workflow`,
`see-versions-workflow`, `test-workflow`, `tidy-up-workflow`
**Workflow version (4)** -- `see-runs-workflow-version`,
`see-versions-workflow-version`, `see-workflow-workflow-version`,
`use-as-draft-workflow-version`
**Workflow run (3)** -- `see-version-workflow-run`,
`see-workflow-workflow-run`, `stop-workflow-run`
|
||
|
Charles Bochet
|
9d57bc39e5 |
Migrate from ESLint to OxLint (#18443)
## Summary Fully replaces ESLint with OxLint across the entire monorepo: - **Replaced all ESLint configs** (`eslint.config.mjs`) with OxLint configs (`.oxlintrc.json`) for every package: `twenty-front`, `twenty-server`, `twenty-emails`, `twenty-ui`, `twenty-shared`, `twenty-sdk`, `twenty-zapier`, `twenty-docs`, `twenty-website`, `twenty-apps/*`, `create-twenty-app` - **Migrated custom lint rules** from ESLint plugin format to OxLint JS plugin system (`@oxlint/plugins`), including `styled-components-prefixed-with-styled`, `no-hardcoded-colors`, `sort-css-properties-alphabetically`, `graphql-resolvers-should-be-guarded`, `rest-api-methods-should-be-guarded`, `max-consts-per-file`, and Jotai-related rules - **Migrated custom rule tests** from ESLint `RuleTester` + Jest to `oxlint/plugins-dev` `RuleTester` + Vitest - **Removed all ESLint dependencies** from `package.json` files and regenerated lockfiles - **Updated Nx targets** (`lint`, `lint:diff-with-main`, `fmt`) in `nx.json` and per-project `project.json` to use `oxlint` commands with proper `dependsOn` for plugin builds - **Updated CI workflows** (`.github/workflows/ci-*.yaml`) — no more ESLint executor - **Updated IDE setup**: replaced `dbaeumer.vscode-eslint` with `oxc.oxc-vscode` extension, configured `source.fixAll.oxc` and format-on-save with Prettier - **Replaced all `eslint-disable` comments** with `oxlint-disable` equivalents across the codebase - **Updated docs** (`twenty-docs`) to reference OxLint instead of ESLint - **Renamed** `twenty-eslint-rules` package to `twenty-oxlint-rules` ### Temporarily disabled rules (tracked in `OXLINT_MIGRATION_TODO.md`) | Rule | Package | Violations | Auto-fixable | |------|---------|-----------|-------------| | `twenty/sort-css-properties-alphabetically` | twenty-front | 578 | Yes | | `typescript/consistent-type-imports` | twenty-server | 3814 | Yes | | `twenty/max-consts-per-file` | twenty-server | 94 | No | ### Dropped plugins (no OxLint equivalent) `eslint-plugin-project-structure`, `lingui/*`, `@stylistic/*`, `import/order`, `prefer-arrow/prefer-arrow-functions`, `eslint-plugin-mdx`, `@next/eslint-plugin-next`, `eslint-plugin-storybook`, `eslint-plugin-react-refresh`. Partial coverage for `jsx-a11y` and `unused-imports`. ### Additional fixes (pre-existing issues exposed by merge) - Fixed `EmailThreadPreview.tsx` broken import from main rename (`useOpenEmailThreadInSidePanel`) - Restored truthiness guard in `getActivityTargetObjectRecords.ts` - Fixed `AgentTurnResolver` return types to match entity (virtual `fileMediaType`/`fileUrl` are resolved via `@ResolveField()`) ## Test plan - [x] `npx nx lint twenty-front` passes - [x] `npx nx lint twenty-server` passes - [x] `npx nx lint twenty-docs` passes - [x] Custom oxlint rules validated with Vitest: `npx nx test twenty-oxlint-rules` - [x] `npx nx typecheck twenty-front` passes - [x] `npx nx typecheck twenty-server` passes - [x] CI workflows trigger correctly with `dependsOn: ["twenty-oxlint-rules:build"]` - [x] IDE linting works with `oxc.oxc-vscode` extension |
||
|
Abdullah.
|
338a38682d |
feat: upgrade nx to latest (#18404)
Upgraded NX to resolve some dependabot alerts caused by transitive dependencies, but after the upgrade, it appears those transitive dependency issues were not fixed by NX in the first place. Creating this PR with the upgrade regardless to avoid wasted work. Used `npx nx@latest migrate latest` from the documentation to automate the upgrade and it bumped all the dependencies changed in `package.json` for compatibility - `react-router-dom` and `swc` ones too. Ran tests, ran builds, started the development server and used the application - everything looks good after the upgrade. |
||
|
Charles Bochet
|
7a2e397ad1 |
Complete linaria migration (#18361)
## Summary
Completes the migration of the frontend styling system from **Emotion**
(`@emotion/styled`, `@emotion/react`) to **Linaria** (`@linaria/react`,
`@linaria/core`), a zero-runtime CSS-in-JS library where styles are
extracted at build time.
This is the final step of the migration — all ~494 files across
`twenty-front`, `twenty-ui`, `twenty-website`, and `twenty-sdk` are now
fully converted.
## Changes
### Styling Migration (across ~480 component files)
- Replaced all `@emotion/styled` imports with `@linaria/react`
- Converted runtime theme access patterns (`({ theme }) => theme.x.y`)
to build-time `themeCssVariables` CSS custom properties
- Replaced `useTheme()` hook (from Emotion) with
`useContext(ThemeContext)` where runtime theme values are still needed
(e.g., passing colors to non-CSS props like icon components)
- Removed `@emotion/react` `css` helper usages in favor of Linaria
template literals
### Dependency & Configuration Changes
- **Removed**: `@emotion/react`, `@emotion/styled` from root
`package.json`
- **Added**: `@wyw-in-js/babel-preset`, `next-with-linaria` (for
twenty-website SSR support)
- Updated Nx generator defaults from `@emotion/styled` to
`@linaria/react` in `nx.json`
- Simplified `vite.config.ts` (removed Emotion-specific configuration)
- Updated `twenty-website/next.config.js` to use `next-with-linaria` for
SSR Linaria support
### Storybook & Testing
- Removed `ThemeProvider` from Emotion in Storybook previews
(`twenty-front`, `twenty-sdk`)
- Now relies solely on `ThemeContextProvider` for theme injection
### Documentation
- Removed the temporary `docs/emotion-to-linaria-migration-plan.md`
(migration complete)
- Updated `CLAUDE.md` and `README.md` to reflect Linaria as the styling
stack
- Updated frontend style guide docs across all locales
## How it works
Linaria extracts styles at build time via the `@wyw-in-js/vite` plugin.
All expressions in `styled` template literals must be **statically
evaluable** — no runtime theme objects or closures over component state.
- **Static styles** use `themeCssVariables` which map to CSS custom
properties (`var(--theme-color-x)`)
- **Runtime theme access** (for non-CSS use cases like icon `color`
props) uses `useContext(ThemeContext)` instead of Emotion's `useTheme()`
|
||
|
Charles Bochet
|
3bfdc2c83f |
chore(twenty-front): migrate command-menu, workflow, page-layout and UI modules from Emotion to Linaria (PR 4-6/10) (#18342)
## Summary
Continues the Emotion → Linaria migration (PR 4-6 from the [migration
plan](docs/emotion-to-linaria-migration-plan.md)). Migrates **311
files** across four module groups:
| Module | Files |
|---|---|
| command-menu | 53 |
| workflow | 84 |
| page-layout | 84 |
| UI (partial - first ~80 files) | ~80 |
| twenty-ui (TEXT_INPUT_STYLE) | 1 |
| misc (hooks, keyboard-shortcut-menu, file-upload) | ~9 |
### Migration patterns applied
- `import styled from '@emotion/styled'` → `import { styled } from
'@linaria/react'`
- `import { useTheme } from '@emotion/react'` → `import { useContext }
from 'react'` + `import { ThemeContext } from 'twenty-ui/theme'`
- `${({ theme }) => theme.X.Y.Z}` → `${themeCssVariables.X.Y.Z}` (static
CSS variables)
- `theme.spacing(N)` → `themeCssVariables.spacing[N]`
- `styled(motion.div)` → `motion.create(StyledBase)` (11 components)
- `styled(Component)<TypeParams>` → wrapper div approach for non-HTML
elements
- Multi-declaration interpolations split into one CSS property per
interpolation
- Interpolation return types fixed (`&&` → ternary `? : ''`)
- `TEXT_INPUT_STYLE` converted from function to static string constant
(backward compatible)
- Emotion `<Global>` replaced with `useEffect` style injection
- Complex runtime-dependent styles use CSS custom properties via
`style={}` prop
### After this PR
- **Remaining files**: ~400 (object-record: ~160, settings: ~200, UI:
~44)
- **No breaking changes**: CSS variables resolve identically to the
previous Emotion theme values
|
||
|
Abdullah.
|
76c7639eb3 |
fix: upgrade storybook to latest to resolve dependabot alert (#18285)
Resolves [Dependabot Alert 509](https://github.com/twentyhq/twenty/security/dependabot/509). Upgraded storybook and related packages to latest, also fixed a failing test to match what the DOM really contains. |
||
|
Abdullah.
|
4ed09a3feb |
Upgrade blocknote dependencies from 0.31.1 to 0.47.0. (#18207)
This PR pgrades all BlockNote packages (@blocknote/core, @blocknote/react, @blocknote/mantine, @blocknote/server-util, @blocknote/xl-docx-exporter, @blocknote/xl-pdf-exporter) to 0.47.0 and adapts the codebase to the new API. ### Changes - Dependency upgrades: Bumped all BlockNote packages to 0.47.0, added required Mantine v8 peer dependencies, removed unnecessary prosemirror resolutions - Formatting toolbar: Replaced the manual reimplementation of FormattingToolbarController (which handled visibility, positioning, portal rendering, text-alignment-based placement, and a dangerouslySetInnerHTML transition trick) with BlockNote's built-in FormattingToolbarController. The toolbar buttons themselves are unchanged. - Side menu: Replaced manual drag handle menu positioning and rendering (DashboardBlockDragHandleMenu, DashboardBlockColorPicker, and their floating configs) with BlockNote's built-in SideMenuController, DragHandleButton, and DragHandleMenu components. Deleted 4 files that became dead code. - Extension API migration: Replaced deprecated editor.suggestionMenus and editor.formattingToolbar APIs with the new extension system (SuggestionMenu, useExtensionState, editor.getExtension()) - Slash menu fixes: Filtered out BlockNote's new default "File" item (added in 0.47) to avoid duplicates with our custom one; added icon mappings for new block types (Toggle List, Divider, Toggle Headings, Headings 4-6) - Server-side: Switched @blocknote/server-util to dynamic import() to handle ESM-only transitive dependencies in CJS context |
||
|
Abdullah.
|
546114d07f |
fix: next-mdx-remote related dependabot alerts (#18244)
Resolves [Dependabot Alert 485](https://github.com/twentyhq/twenty/security/dependabot/485) and [Dependabot Alert 486](https://github.com/twentyhq/twenty/security/dependabot/486). Bumped up `next-mdx-remote` to v6.0.0 and `remark-gfm` to v4.0.1 for compatibility - no breaking changes for our use-case. |
||
|
Charles Bochet
|
121788c42f |
Fully deprecate old recoil (#18210)
## Summary Removes the `recoil` dependency entirely from `package.json` and `twenty-front/package.json`, completing the migration to Jotai as the sole state management library. Removes all Recoil infrastructure: `RecoilRoot` wrapper from `App.tsx` and test decorators, `RecoilDebugObserver`, Recoil-specific ESLint rules (`use-getLoadable-and-getValue-to-get-atoms`, `useRecoilCallback-has-dependency-array`), and legacy Recoil utility hooks/types (`useRecoilComponentState`, `useRecoilComponentValue`, `createComponentState`, `createFamilyState`, `getSnapshotValue`, `cookieStorageEffect`, `localStorageEffect`, etc.). Renames all `V2`-suffixed Jotai state files and types to their canonical names (e.g., `ComponentStateV2` -> `ComponentState`, `agentChatInputStateV2` -> `agentChatInputState`, `SelectorCallbacksV2` -> `SelectorCallbacks`), and removes the now-redundant V1 counterparts. Updates ~433 files across the codebase to use the renamed Jotai imports, remove Recoil imports, and clean up test wrappers (`RecoilRootDecorator` -> `JotaiRootDecorator`). |
||
|
Félix Malfait
|
0e25aeb5be |
chore: upgrade @swc/core to 1.15.11 and align SWC ecosystem (#18088)
## Summary - Upgrades `@swc/core` from 1.13.3 to **1.15.11** (swc_core v56), which introduces CBOR-based plugin serialization replacing rkyv, eliminating strict version-matching between SWC core and Wasm plugins - Upgrades `@lingui/swc-plugin` from ^5.6.0 to **^5.11.0** (swc_core 50.2.3, built with `--cfg=swc_ast_unknown` for cross-version compatibility) - Upgrades `@swc/plugin-emotion` from 10.0.4 to **14.6.0** (swc_core 53, also with backward-compat feature) - Upgrades companion packages: `@swc-node/register` 1.8.0 → 1.11.1, `@swc/helpers` ~0.5.2 → ~0.5.18, `@vitejs/plugin-react-swc` 3.11.0 → 4.2.3 ### Why this is safe now Starting from `@swc/core v1.15.0`, SWC replaced the rkyv serialization scheme with CBOR (a self-describing format) and added `Unknown` AST enum variants. Plugins built with `swc_core >= 47` and `--cfg=swc_ast_unknown` are now forward-compatible across `@swc/core` versions. Both `@lingui/swc-plugin@5.10.1+` and `@swc/plugin-emotion@14.0.0+` have this support, meaning the old version-matching nightmare between Lingui and SWC is largely solved. Reference: https://github.com/lingui/swc-plugin/issues/179 ## Test plan - [x] `yarn install` resolves without errors - [x] `npx nx build twenty-shared` succeeds - [x] `npx nx build twenty-ui` succeeds (validates @swc/plugin-emotion@14.6.0) - [x] `npx nx typecheck twenty-front` succeeds - [x] `npx nx build twenty-front` succeeds (validates vite + swc + lingui pipeline) - [x] `npx nx build twenty-emails` succeeds (validates lingui plugin) - [x] Frontend jest tests pass (validates @swc/jest + @lingui/swc-plugin) - [x] Server jest tests pass (validates server-side SWC + lingui) Made with [Cursor](https://cursor.com) --------- Co-authored-by: Cursor <cursoragent@cursor.com> |
||
|
Félix Malfait
|
216a7331f8 |
Speed up twenty-emails build by replacing vite-plugin-dts with tsgo (#17857)
## Summary - Removed `vite-plugin-dts` (which used `tsc` internally) from the Vite build and replaced DTS generation with `tsgo` as a sequential post-build step — **~0.7s vs 1-10s**. - Disabled `reportCompressedSize` to skip gzip computation for 64 output files. - Converted the build target to an explicit `nx:run-commands` executor with sequential `vite build` → `tsgo` commands. The `twenty-emails:build` step goes from ~22s to ~7s under load. ## Test plan - [x] `nx build twenty-emails` produces both JS (64 files) and DTS (74 files) correctly - [x] `dist/index.d.ts` exports match the source `src/index.ts` - [x] Full `nx build twenty-server` succeeds end-to-end - [ ] CI build passes Made with [Cursor](https://cursor.com) --------- Co-authored-by: Cursor <cursoragent@cursor.com> |
||
|
Charles Bochet
|
d2f8352cb8 |
Start Jotai Migration (#17893)
## Recoil → Jotai progressive migration: infrastructure + ChipFieldDisplay ### Benchmark In the beginning, there was no hope: <img width="1180" height="948" alt="image" src="https://github.com/user-attachments/assets/f8635991-52e6-4958-8240-6ba7214132b2" /> Then the hope was reborn <img width="2070" height="948" alt="image" src="https://github.com/user-attachments/assets/be1182b9-1c8d-4fdc-ab4c-1484ad74449d" /> ### Approach We introduce a **V2 state management layer** backed by Jotai that mirrors the existing Recoil API, enabling component-by-component migration without a big-bang rewrite. #### V2 API (Jotai-backed, Recoil-ergonomic) - `createStateV2` / `createFamilyStateV2` — drop-in replacements for `createState` / `createFamilyState`, returning wrapper types over Jotai atoms - `useRecoilValueV2`, `useRecoilStateV2`, `useFamilyRecoilValueV2`, etc. — thin wrappers around Jotai's `useAtomValue` / `useAtom` / `useSetAtom` - A shared `jotaiStore` (via `createStore()`) passed to a `<JotaiProvider>` wrapping `<RecoilRoot>`, also accessible imperatively for dual-writes #### Dual-write bridge for progressive migration For state shared between migrated and non-migrated components, we use **dual-write**: writers update both the Recoil atom and the Jotai V2 atom (via `jotaiStore.set()`). This avoids sync components or extra subscriptions. Write sites updated: `useUpsertRecordsInStore`, `useSetRecordTableData`, `ListenRecordUpdatesEffect`, `RecordShowEffect`, `useLoadRecordIndexStates`, `useUpdateObjectViewOptions`. #### First migration: ChipFieldDisplay render path - `useChipFieldDisplay` → reads `recordStoreFamilyStateV2` via `useFamilyRecoilValueV2` (was `useRecoilValue(recordStoreFamilyState)`) - `RecordChip` → reads `recordIndexOpenRecordInStateV2` via `useRecoilValueV2` (was `useRecoilValue(recordIndexOpenRecordInState)`) - `Avatar` (twenty-ui) and event handlers (`useOpenRecordInCommandMenu`) left on Recoil — not on the render path / in a different package #### Pattern for migrating additional state 1. Create V2 atom: `createStateV2` or `createFamilyStateV2` 2. Add `jotaiStore.set(v2Atom, value)` at each write site 3. Switch readers to `useRecoilValueV2(v2Atom)` 4. Once all readers are migrated, remove the Recoil atom and dual-writes #### Why not jotai-recoil-adapter? Evaluated [jotai-recoil-adapter](https://github.com/clockelliptic/jotai-recoil-adapter) — not production-ready (21 open issues, no React 19, forces providerless mode, missing types). We built a purpose-built thin layer instead. |
||
|
dependabot[bot]
|
08b962b0d2 |
Bump @vitest/browser-playwright from 4.0.17 to 4.0.18 (#17884)
Bumps
[@vitest/browser-playwright](https://github.com/vitest-dev/vitest/tree/HEAD/packages/browser-playwright)
from 4.0.17 to 4.0.18.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/vitest-dev/vitest/releases"><code>@vitest/browser-playwright</code>'s
releases</a>.</em></p>
<blockquote>
<h2>v4.0.18</h2>
<h3> 🚀 Experimental Features</h3>
<ul>
<li><strong>experimental</strong>: Add <code>onModuleRunner</code> hook
to <code>worker.init</code> - by <a
href="https://github.com/sheremet-va"><code>@sheremet-va</code></a> in
<a
href="https://redirect.github.com/vitest-dev/vitest/issues/9286">vitest-dev/vitest#9286</a>
<a href="https://github.com/vitest-dev/vitest/commit/ea837de7d"><!-- raw
HTML omitted -->(ea837)<!-- raw HTML omitted --></a></li>
</ul>
<h3> 🐞 Bug Fixes</h3>
<ul>
<li>Use <code>meta.url</code> in <code>createRequire</code> - by <a
href="https://github.com/sheremet-va"><code>@sheremet-va</code></a> in
<a
href="https://redirect.github.com/vitest-dev/vitest/issues/9441">vitest-dev/vitest#9441</a>
<a href="https://github.com/vitest-dev/vitest/commit/e057281ca"><!-- raw
HTML omitted -->(e0572)<!-- raw HTML omitted --></a></li>
<li><strong>browser</strong>: Hide injected data-testid attributes -
by <a
href="https://github.com/sheremet-va"><code>@sheremet-va</code></a> in
<a
href="https://redirect.github.com/vitest-dev/vitest/issues/9503">vitest-dev/vitest#9503</a>
<a href="https://github.com/vitest-dev/vitest/commit/f89899cd8"><!-- raw
HTML omitted -->(f8989)<!-- raw HTML omitted --></a></li>
<li><strong>ui</strong>: Process artifact attachments when generating
HTML reporter - by <a
href="https://github.com/macarie"><code>@macarie</code></a> in <a
href="https://redirect.github.com/vitest-dev/vitest/issues/9472">vitest-dev/vitest#9472</a>
<a href="https://github.com/vitest-dev/vitest/commit/225435647"><!-- raw
HTML omitted -->(22543)<!-- raw HTML omitted --></a></li>
</ul>
<h5> <a
href="https://github.com/vitest-dev/vitest/compare/v4.0.17...v4.0.18">View
changes on GitHub</a></h5>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="
|
||
|
Félix Malfait
|
161689be18 |
feat: fix junction toggle persistence and add type-safe documentation paths (#17421)
## Summary - **Fix junction relation toggle not being saved**: The form schema wasn't tracking the `settings` field, so changes to `junctionTargetFieldId` weren't marked as dirty - **Add type-safe documentation paths**: Generate TypeScript constants from `base-structure.json` to prevent broken documentation links - **Create many-to-many relations documentation**: Step-by-step guide for building many-to-many relations using junction objects - **Update `getDocumentationUrl`**: Now uses shared constants from `twenty-shared` for base URL, default path, and supported languages ## Key Changes ### Junction Toggle Fix - Added `settings` field to the form schema in `SettingsDataModelFieldRelationForm.tsx` - Fixed the toggle to properly merge settings when updating `junctionTargetFieldId` ### Type-Safe Documentation Paths - New constants in `twenty-shared/constants`: - `DOCUMENTATION_PATHS` - All 161 documentation paths as typed constants - `DOCUMENTATION_SUPPORTED_LANGUAGES` - 14 supported languages - `DOCUMENTATION_BASE_URL` / `DOCUMENTATION_DEFAULT_PATH` - Generator script: `yarn docs:generate-paths` - CI integration: Added to `docs-i18n-pull.yaml` workflow ### Documentation - New article: `/user-guide/data-model/how-tos/create-many-to-many-relations` - Updated `/user-guide/data-model/capabilities/relation-fields.mdx` with Lab warning and link ## Test plan - [ ] Verify junction toggle saves correctly when enabled/disabled - [ ] Verify documentation link opens correct localized page - [ ] Verify `yarn docs:generate-paths` regenerates paths correctly |
||
|
Félix Malfait
|
dc93cf4c59 |
feat: add TypeScript Go (tsgo) for faster type checking (#17211)
## Summary - Add `@typescript/native-preview` (tsgo) for dramatically faster type checking on frontend projects - Configure tsgo as default for frontend projects (twenty-front, twenty-ui, twenty-shared, etc.) - Keep tsc for twenty-server (faster for NestJS decorator-heavy code) - Fix type imports for tsgo compatibility (DOMPurify, AxiosInstance) - Remove deprecated `baseUrl` from tsconfigs where safe ## Performance Results | Project | tsgo | tsc -b | Speedup | |---------|------|--------|---------| | **twenty-front** | 1.4s | 60.7s | **43x faster** | | **twenty-server** | 2m42s | 1m10s | tsc is faster (decorators) | tsgo excels at modern React/JSX codebases but struggles with decorator-heavy NestJS backends, so we use the optimal checker for each. ## Usage ```bash # Default (tsgo for frontend, tsc for backend) nx typecheck twenty-front nx typecheck twenty-server # Force tsc fallback if needed nx typecheck twenty-front --configuration=tsc # Force tsgo on backend (slower, not recommended) nx typecheck twenty-server --configuration=tsgo ``` ## Test plan - [x] `nx typecheck twenty-front` passes with tsgo - [x] `nx typecheck twenty-server` passes with tsc - [x] `nx run-many -t typecheck --exclude=fireflies` passes - [ ] CI tests pass |
||
|
Abdullah.
|
92eff62523 | Replace test-runner with vitest for storybook (#17187) | ||
|
Félix Malfait
|
c737028dd6 |
Move tools/eslint-rules to packages/twenty-eslint-rules (#17203)
## Summary Moves the custom ESLint rules from `tools/eslint-rules` to `packages/twenty-eslint-rules` for better organization within the monorepo packages structure. ## Changes - Move `eslint-rules` from `tools/` to `packages/twenty-eslint-rules` - Use `loadWorkspaceRules` from `@nx/eslint-plugin` to load custom rules - Update all ESLint configs to use the `twenty/` rule prefix instead of `@nx/workspace-` - Update `project.json`, `jest.config.mjs` with new paths - Update `package.json` workspaces and `nx.json` cache inputs - Update Dockerfile reference ## Technical Details The custom ESLint rules are now loaded using Nx's `loadWorkspaceRules` utility which: - Handles TypeScript transpilation automatically - Allows loading workspace rules from any directory - Provides a cleaner approach than the previous `@nx/workspace-` convention ## Testing - Verified all 17 custom ESLint rules load correctly from the new location - Verified linting works on dependent packages (twenty-front, twenty-server, etc.) |