## What this does
Resolves the remaining esbuild security alerts on packages we own, and
upgrades the repo to **Vite 8** (which drops esbuild entirely in favour
of rolldown/oxc).
### 1. esbuild → `^0.28.1` (security)
- Raised the declared `esbuild` floor in `twenty-sdk` and the
logic-function common-layer (both were `^0.25.0`, which can only resolve
to a vulnerable version). These are our packages, so this is just
declaring the patched version — clears Dependabot **#1467** and
**#1468**.
### 2. Vite 7 → 8
- Bumped `vite` to `^8` in the 5 packages that declare it, and
`@vitejs/plugin-react-swc` to `^4.3.1` (the only plugin that needed a
bump for Vite 8; everything else already supports it).
- `twenty-front` keeps esbuild minification, so esbuild is now an
explicit (patched) devDependency there — Vite 8 no longer ships it.
### Two Vite-8 fallout fixes (bundler internals changed)
- **Storybook tests:** added React to `optimizeDeps.include` so Vite's
dep optimizer doesn't re-bundle React mid-run and break in-flight
imports in browser-mode tests.
- **`hex-rgb`:** it's ESM-only and broke rolldown's CJS interop (a
default import resolved to the wrong thing under jest). Replaced its one
use with a tiny inline hex→rgb parse and dropped the dependency.
## Verified
Vite resolves to a single `8.0.16` with no esbuild in its tree. Builds
pass on Vite 8/rolldown: `twenty-front` production build, the SDKs, and
Storybook; the previously-failing front and storybook test jobs now
pass; `yarn install --immutable` is clean.
## Note
This doesn't close root alert **#1469** — esbuild is still pulled by
other third-party tools (storybook, tsx, lingui, zapier, etc.) that
haven't shipped a patched release. The vulnerable code path (esbuild's
dev server) isn't used here, so that one is best dismissed as
not-affected.
## Context
AWS Inspector flags the `prod-twenty` image (built from current main)
with 16 findings, and Dependabot alert 174 flags esbuild. This PR fixes
the OpenSSL scanner findings and the esbuild CVE. The typeorm bump
(CVE-2025-60542) was **pulled out of this PR** — see "typeorm status"
below.
## Changes
### Strip `/usr/local/include/node` from runtime stages
(`twenty-server`, `twenty-app-dev`)
15 OpenSSL CVEs (June 9 advisory, incl. CRITICAL CVE-2026-34182) are all
detected via **Node's bundled OpenSSL dev headers**: 3 GENERIC
`openssl/openssl` 3.5.6 detections per CVE at
`/usr/local/include/node/openssl/archs/linux-x86_64/{asm,asm_avx2,no-asm}/include/openssl/opensslv.h`.
The headers are only needed by node-gyp and native addons are compiled
in the build stages — nothing compiles at runtime. Dropping them clears
all 45 detection instances and permanently ends this class of finding
(third occurrence: 3.5.5 → 3.5.6 → 3.5.7). None of these CVEs are
reachable through Node (no CMS/PKCS#7 API, `pfx` is operator-supplied,
Node's QUIC uses ngtcp2, ASN.1 issues need ~2GB inputs).
**Follow-up (~June 17, 2026):** the `node` binary itself still
statically links OpenSSL 3.5.6 — invisible to the scanner after this PR
and unreachable in practice, but the real fix is bumping the pinned
`node:24-alpine` digest once the [announced June 17 Node.js security
releases](https://nodejs.org/en/blog/vulnerability/june-2026-security-releases)
ship a 24.x linking OpenSSL ≥ 3.5.7 (verify via
`deps/openssl/openssl/VERSION.dat` on the release tag — 24.16.0 is still
on 3.5.6). A dated TODO sits next to the cleanup in the Dockerfile.
### esbuild dev-server CORS CVE (Dependabot alert 174,
GHSA-67mh-4wv8-2f99)
`@lingui/cli@5.1.2` (pins `esbuild ^0.21.5`) was the last parent
resolving a vulnerable esbuild (≤ 0.24.2 lets any website send requests
to the dev server and read responses). Instead of a resolution override,
this bumps the lockstepped **lingui suite 5.1.2 → 5.9.5** (within-major;
lingui adopted `esbuild ^0.25.1` in 5.4.1), which:
- removes `esbuild@0.21.5` and all its platform packages from the
lockfile with no forced ranges;
- drops the `@lingui/core` lockstep resolution (its comment marked it
droppable on the next coordinated lingui bump — the tree now resolves a
single `@lingui/core@5.9.5`);
- `@lingui/swc-plugin` stays at `^5.11.0` (peers on `@lingui/core: 5`;
its 6.x line targets lingui 6).
**lingui 5.9.5 behavioral fallout handled here:**
- Translation functions now **throw without an active locale** (5.1.2
fell back silently). The global `i18n` singleton that backs server-side
`` t`…` `` calls only had a messages compiler set, never an activated
locale → activate the source locale in `I18nService.loadTranslations()`,
mirrored in the server jest setup (unit tests bypass Nest bootstrap).
- `msg`/`t` placeholders are now strictly typed (reject
`null`/`undefined`/`unknown`) → one server call site and 16 twenty-front
files adapted with minimal nullish-coalescing fixes that preserve
rendering.
- `.po`/compiled-catalog churn from the new extractor/compiler
(reference reordering, sorted keys — verified content-identical on
unchanged `.po` inputs) is intentionally not committed: the scheduled
i18n workflows regenerate those.
## typeorm status (pulled out)
typeorm 0.3.20 → 0.3.26 was originally in this PR but **made workspace
metadata sync intermittently lossy**: `example-app-postcard` failed
twice with a *different* field missing from the synced PostCard object
each run, and one integration shard's `DataSeedWorkspaceCommand` died
with "Could not find flat entity with universal identifier …" — versus
zero such failures on recent main. Local runs (db reset + seed, group-by
integration suite 19/19) pass, so it is a nondeterministic
CI-load-sensitive regression that needs dedicated debugging (typeorm
changed LIMIT/OFFSET 0 semantics, lazy count for `getManyAndCount`,
upsert WHERE construction, and topological-sort internals in that
range). The resolutions comment documents this as the blocker;
CVE-2025-60542 is MySQL-driver-only (`sqlstring`), so Postgres-only
Twenty is not exposed in the meantime.
## Verification
- `npx nx typecheck twenty-server` / `twenty-front` — clean (no cache)
- `npx nx test twenty-server` — full suite green
- `lingui:extract` + `lingui:compile` — clean for twenty-server /
twenty-emails / twenty-front
- `oxfmt --check` — clean for both packages
- Lockfile diff: lingui 5.9.5 entries, `esbuild@0.21.5` +
`@esbuild/*@0.21.5` platform packages removed, no typeorm changes
## What
Clears **all 9 High `next` Dependabot alerts** (incl.
GHSA-26hh-7cqf-hhc6) in twenty-emails — via a parent bump, no
resolutions.
All 9 traced to a stale **`next@16.0.10`** pulled by
`@react-email/preview-server` 5.x. The latest preview-server 5.x still
ships a vulnerable next (16.1.7 < 16.2.6), so bumping it alone wouldn't
help. **react-email 6.x** is a rewrite that no longer depends on next or
on a separate preview-server.
- bump `react-email` `5.1.0` → `6.5.0`
- remove the obsolete `@react-email/preview-server` devDependency
- add `@react-email/ui` `6.5.0` devDependency
### Why `@react-email/ui` (the CI fix)
react-email 6's `email dev` preview server loads its UI from
`@react-email/ui`, and **prompts to install it interactively** if
missing — which hangs the `emails-test` CI job (no TTY), so the server
never starts and the `/preview/test.email` smoke check fails. Pinning
`@react-email/ui` makes `email dev` start non-interactively.
### Net effect on `next`
The vulnerable `16.0.10` is gone. `@react-email/ui@6.5.0` pulls
**`next@16.2.6`** — the **patched** version (≥ every current next
advisory fix), so all 9 alerts clear and **no vulnerable next remains**.
## Notes
- `react-email` and `@react-email/ui` pinned to exact `6.5.0` (matching
the prior react-email pin) because the `6.6.0` line was published today
and is still registry-quarantined.
- react-email is a dev-only preview tool; CI builds emails via `vite` +
typecheck.
## Verification
- No `next < 16.2.6` in `yarn.lock`
- `nx build` + `nx typecheck` twenty-emails
- `email dev -d src/emails -p 4001` starts non-interactively and serves
`/preview/test.email` → HTTP 200 (reproduces the emails-test check, now
passing)
- `yarn install --immutable` clean
## What
Clears **all 14 High `minimatch` ReDoS alerts** (GHSA-7r86-cg39-jmmj,
GHSA-23c5-xmqv-rm74, GHSA-3ppc-4f35-3m26) in the root tree — **by
bumping the actual parent dev tools, with no `resolutions`/overrides**.
Each parent that pinned a vulnerable minimatch is upgraded so the
patched version resolves naturally.
| Vulnerable minimatch | Pinned by | Fix |
|---|---|---|
| 10.0.3 | `@microsoft/api-extractor` 7.55.1 | → 7.58.7 (in-range
refresh) → minimatch 10.2.3 |
| 3.1.2 | `@stoplight/spectral-core` 1.20.0 | → 1.23.0 (in-range
refresh) → minimatch ^3.1.4 |
| 3.0.8 | `vite-plugin-dts` 3.8.1 → api-extractor 7.43.0 | bump to
`^4.5.4` (already used elsewhere here) → minimatch 10.2.3 |
| 4.2.3 | `graphql-config` 4.5.0 via `@graphql-codegen/cli` ^3.3.1 |
bump cli to `^5.0.7` → graphql-config 5.1.6 → minimatch ^10 |
| 9.0.3 | `zapier-platform-cli` ^15.4.1 | bump to `^19.0.0` |
| 7.4.6 | `verdaccio` 6.5.2 → `@verdaccio/core` 8.0.0-next | refresh to
6.7.2 → core 8.1.1 → minimatch 7.4.9 |
All six are **build/test tooling** — the ReDoS exposure is build-time,
never shipped to users.
## Verification
- ✅ Every resolved `minimatch` in `yarn.lock` is now ≥ its patched floor
(3.1.5 / 7.4.9 / 9.0.9 / 10.2.3+). No `resolutions` added.
- ✅ `nx build`: twenty-shared, twenty-ui, twenty-ui-deprecated,
twenty-emails (validates vite-plugin-dts v4)
- ✅ twenty-zapier: typecheck + build + `zapier validate` (35/35 checks
pass; cli 19 + core 15.5.1)
- ✅ twenty-front: typecheck; `graphql:generate` with codegen cli 5
produces **byte-identical** output (no generated-file changes in this
PR)
- ✅ `yarn install --immutable` clean
## Notes
- The large `yarn.lock` diff is expected: major bumps to codegen (3→5),
zapier-cli (15→19), and vite-plugin-dts (3→4) cascade through dev-tree
transitives (net −1244 lines after dedup).
- `zapier-platform-core` (runtime) intentionally left at 15.5.1 — only
the CLI (dev tool) carried the vulnerable minimatch; `zapier validate`
flags only a non-blocking "consider upgrading core" suggestion.
- codegen plugins (`typescript`/`typescript-operations`) left at v3:
they run fine under cli 5 and produce identical output, so the minimal
change is just the cli bump.
## 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>
I was looking into [Dependabot Alert
107](https://github.com/twentyhq/twenty/security/dependabot/107) and
figured that the alert is caused by `vite-plugin-dts`, which is a
development dependency and does not make it into the production build
for it to be dangerous.
However, while at it, I also saw that some packages used plugins from
root package.json while others had them defined in their local
package.json. Therefore, I refactored to move plugins where they're
required and removed a redundant package.
Builds for the following succeed as intended:
- twenty-ui
- twenty-emails
- twenty-website
- twenty-front
Co-authored-by: Félix Malfait <felix.malfait@gmail.com>
Fixes [Dependabot Alert
216](https://github.com/twentyhq/twenty/security/dependabot/216) -
authorization bypass in next.js middleware.
Updated `react-email` version from `4.0.3` to `4.0.4`. This bumps up
Next.js to a safer version for the mentioned critical alert. However,
even the latest `react-email` package has not upgraded to Next.js 15.4.7
- the recommended version by dependabot.
Since `react-email` is a devDependency used to preview email templates
during development, it never gets inserted into the production build.
Therefore, I marking the following alerts as `vulnerable code is never
used` with a comment that it never makes it to the production build.
<p align="center">
<img width="1142" height="342" alt="image"
src="https://github.com/user-attachments/assets/50976fd3-b49c-4ee7-ac26-89f505783d55"
/>
</p>
The only other place where we have next imported is twenty-website,
which uses the safe version `14.2.33`.
<p align="center">
<img width="421" height="92" alt="image"
src="https://github.com/user-attachments/assets/fe1e20dc-7483-44f7-bf26-78f7131ccf46"
/>
</p>
Unless I'm mistaken the project does not run with node `24.0.0`
Switching to node `24.5.0` ( as defined in vscode node runtime
requirements in https://github.com/twentyhq/twenty/pull/13730 ) seems to
fix the issue
```ts
Successfully compiled: 2897 files with swc (188.32ms)
(node:77006) [DEP0190] DeprecationWarning: Passing args to a child process with shell option true can lead to security vulnerabilities, as the arguments are not escaped, only concatenated.
(Use `node --trace-deprecation ...` to show where the warning was created)
Watching for file changes.
/Users/paulrastoin/ws/twenty/node_modules/buffer-equal-constant-time/index.js:37
var origSlowBufEqual = SlowBuffer.prototype.equal;
^
TypeError: Cannot read properties of undefined (reading 'prototype')
```
Updating engines so local constraint suggest a functional node version
BlocknoteJS requires an ESM module where our server is CJS, this forced
us to pin the server-util version, which led us to force the resolution
of several packages, leading to bugs downstream.
From Node 22.12 Node supports requiring ESM modules (available from Node
22.0 with a flag). So I upgrade the module.
I picked Node 22 and not Node 23 or Node 24 because 22 is the LTS and we
don't plan to change node versions frequently.
If you remain on Node 18, things should still mostly work, except if you
edit a Rich Text field.
I also starting changing the default runtime for Serverless Functions
which isn't directly related. This means new serverless functions will
be created on Node 22, but we will still need another PR to migrate
existing serverless functions before September (end of support by AWS).
(In this PR I also remove the upgrade commands from 0.43 since they rely
on Blocknote and I didn't want to have to deal with this)
---------
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
Now the source of truth for the version is set during the build process.
We set it as an environment variable from the tags.
We could add it back to the package.json during the build process (from
the git tag), but there is not use for it at the moment since it's not
npm packages.
Advanced mode toggle was in `twenty-ui` which doesn't support Lingui.
I removed lingui from the global package json and moved it to the local
package.json instead to prevent that kind of error from happening again
# Introduction
Defined `dependsOn` for each nx project's configuration that has a
dependency to another local package ( ui, shared ).
As follows:
```json
"dependsOn": ["^build"]
```
Where the `^` symbol means "all dependencies of this project"
Now on a fresh repo, no built or install deps after install dependencies
you can directly hit `npx nx build PROJECT_NAME`
closes https://github.com/twentyhq/core-team-issues/issues/371
Related what was failing
[run](https://github.com/twentyhq/twenty-infra/actions/runs/13141544809/job/36669643182)
Cancelled before deploy, attested build was correct within the publish
and digest
One of the steps to address #8128
How to test:
Please change the locale in the settings and click on change password
button. A password reset email in the preferred locale will be sent.
Todo:
- Remove the hardcoded locales for invitation, warn suspended workspace
email, clean suspended workspace emails
- Need to test invitation, email verification, warn suspended workspace
email, clean suspended workspace emails
- The duration variable `5 minutes` is always in english. Do we need to
do something about that? It does seems odd in case of chinese
translations.
Notes:
- Only tested the password reset , password update notify templates.
- Cant test email verification due to error during sign up `Internal
server error: New workspace setup is disabled`
---------
Co-authored-by: Félix Malfait <felix@twenty.com>
Fix all the broken CIs :p
This includes an ongoing effort to simplify test maintenance by having 1
unique source of truth about metadata and data mocks (that will later be
generated from a unique source of seeds: dev = demo = test)
Regressions:
- Unit line coverage: 60 > 55
- Storybook Pages branch coverage: 40 > 35
We will need to write tests to increase those coverage
- RelationFieldDisplay perf: 0.2ms to 0.22ms > We might have a
regression here
- Removed perf story about RawJSON > We will need to re-add it
We are updating our git worklow.
Case 1: **URGENT / PATCH**
If you want to include something URGENT that cannot wait for the next
release, you'll need to:
- create a PR from the latest patch (right now v0.30.1)
- create a new patch tag from this PR (would be v0.30.2 right now)
- merge this PR in main so it's in 0.31 too
Case 2: **REGULAR**
- Open a PR from main and merge it into main
I'm tagging main as v0.31.canary to make it clear!
In this PR:
- update your environment variables to default `CACHE_STORAGE_TYPE` to
`redis` and `MESSAGE_QUEUE_TYPE` to `bull-mq`
- add redis container to our default docker-compose
- add `REDIS_HOST` and `REDIS_PORT` to docker-compose yaml
- add upgrade instructions
Charles Bochet
