## 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
Closes#15970
Select and Multi Select fields did not show up in the Zapier
integration.
## Root cause
`computeInputFields` only emitted input fields for an explicit
allow-list of field types and silently dropped everything else, so
`SELECT` and `MULTI_SELECT` were never surfaced.
On top of that, `SELECT`, `MULTI_SELECT` and `RATING` are **GraphQL
enums** in Twenty's API. Their values must be sent as unquoted enum
literals in a mutation (`stage: SCREENING`), but `handleQueryParams`
quoted every string value (`stage: "SCREENING"`), which produces an
invalid mutation. So even surfacing the fields would not have been
enough to create/update records.
## Changes
- Surface `SELECT` (string) and `MULTI_SELECT` (string list) as input
fields in `computeInputFields`.
- Fetch field `options` in the metadata query and expose them as Zapier
`choices` (`value -> label`) so users pick from the real options instead
of typing raw enum values.
- Emit enum field values **unquoted** in create/update mutations. This
is derived from the object schema in `crud_record` and threaded into
`handleQueryParams`. This also fixes `RATING`, which was silently broken
for the same reason.
## Tests
- `computeInputFields`: new test asserting `SELECT`/`MULTI_SELECT`
produce the right fields with `choices` and `list`.
- `handleQueryParams`: new test asserting enum values are emitted
unquoted (scalar and array).
```
Test Suites: 2 passed
Tests: 5 passed
```
<!-- This is an auto-generated description by cubic. -->
<a
href="https://cubic.dev/pr/twentyhq/twenty/pull/21509?utm_source=github"
target="_blank" rel="noopener noreferrer"
data-no-image-dialog="true"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source
media="(prefers-color-scheme: light)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img
alt="Review in cubic"
src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a>
<!-- End of auto-generated description by cubic. -->
Closes the remaining lodash Dependabot alerts **without any
`resolutions` override** — by upgrading the parent packages that pinned
the vulnerable lodash. Every `lodash` in the tree now resolves to
**4.18.1**.
### Closes
- **#824 — `_.template` code injection (HIGH)**
- #823 / #385 — prototype pollution in `_.unset` / `_.omit`
### What changed (4 parents pinned vulnerable lodash 4.17.x; all
upgraded, no override)
- **`@stoplight/spectral-functions`** → 1.10.2 (in-range; now uses
`lodash ^4.18.1`)
- **`zapier-platform-core`** 15.5.1 → 19.0.0 — aligns with the
already-present `zapier-platform-cli ^19` (they were mismatched). v19
tightened the `Bundle` types, so 3 call sites now type their bundle as
`Bundle<InputData>` and the test bundle includes the new `meta` fields.
- **`@graphql-codegen`** → `cli 6.3.1`, `typescript 5.0.10`,
`typescript-operations 5.1.0`, `typed-document-node 6.1.8`. These depend
on `@graphql-codegen/plugin-helpers ^6.3.0`, the release that dropped
lodash. (Stayed on the 6.x/5.x line on purpose — 7.x changes generated
output far more.)
### About the generated-file changes — they are cosmetic, not real
changes
The codegen bump touches one generated file. **Verified there is zero
semantic change:**
- Only `src/generated-metadata/graphql.ts` changes.
`src/generated/graphql.ts` (data) and `src/generated-admin/graphql.ts`
(admin) are **byte-identical**.
- Same 1,638 type declarations before and after — none added, none
removed.
- After stripping whitespace and union pipes, the file is
**byte-for-byte identical** — no type, field, or union member changed.
The entire diff is one formatting change from
`typescript-operations@5.x`: multi-member union types are now printed
multi-line with a leading `|` instead of on one line — which TypeScript
treats identically:
```ts
// before
payload?: { …ObjectMetadata… } | { …Path… } | null
// after
payload?:
| { …ObjectMetadata… }
| { …Path… }
| null
```
Only metadata is affected because only its operations select GraphQL
union types. To keep generated types otherwise behavior-identical,
`defaultScalarType: 'any'` was added to the three codegen configs
(codegen 6 would otherwise default unmapped scalars to `unknown`).
### Verification
- `twenty-front` typecheck ✓, `twenty-zapier` typecheck ✓
- `yarn install --immutable` ✓ (passes the hardened 3-day age gate)
- CI green — including the `graphql:generate` freshness check, which
regenerates against the canonical schema and confirms the committed
output is exactly what codegen produces
- No `lodash@4.17.x` remains anywhere in `yarn.lock`
Supersedes #21411 (which closed these via a one-line resolution).
## 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.
# Migrate Company and Person standard fields in preparation for the
enrichment app
## Why
Our standard `Person`/`Company` objects accumulated fields that aren't
generic to every
business, while missing a more universal revenue field that essentially
every CRM ships.
This PR makes the **Standard application** hold a tighter, more
universal set of fields,
and sets the stage for a follow-up PR that introduces a **People Data
Labs enrichment app**
to populate them.
## What changes
### Standard fields
**Demoted (Standard → Workspace Custom application)** — not generic
enough to ship as standard:
| Object | Field | Type |
| ------- | ------------------------------ | -------- |
| Company | annualRecurringRevenue (ARR) | CURRENCY |
| Company | employees | NUMBER |
| Company | idealCustomerProfile (ICP) | BOOLEAN |
| Company | xLink (X/Twitter) | LINKS |
| Person | xLink (X/Twitter) | LINKS |
| Person | city | TEXT |
**Added (new generic Standard field)** — present in
Salesforce/HubSpot/Zoho, PDL-populatable:
| Object | Field | Type |
| ------- | ------------- |
-------------------------------------------------------- |
| Company | annualRevenue | CURRENCY (generic total revenue; replaces
the niche ARR) |
### Behavior by workspace
* **New workspaces:** demoted fields are gone; `annualRevenue` is
**active**.
* **Existing workspaces:** demoted fields are **preserved as active
custom fields, data intact**;
`annualRevenue` is created **inactive (opt-in)** with its column ready,
so a later activation
is a metadata-only toggle.
### Upgrade commands (v2.9)
Three idempotent, per-workspace commands, run in timestamp order:
1. **`upgrade:2-9:move-demoted-standard-fields-to-custom-application`**
(1799000040000) —
re-owns the 6 demoted fields to the workspace custom application
(`isCustom = true`,
new `applicationId` + fresh `universalIdentifier`), keeping their data
and active state.
2. **`upgrade:2-9:rename-conflicting-custom-fields`** (1799000045000) —
if a workspace already
has a *custom* field named `annualRevenue`, renames it to
`annualRevenueCustom`
(data preserved via column rename) so the standard field can be added.
Skips non-custom matches.
3. **`upgrade:2-9:add-inactive-generic-standard-fields`**
(1799000050000) — creates
`Company.annualRevenue` on existing workspaces as inactive, guarded to
skip workspaces
missing the target object or where the name is still taken.
**Failure model:** the workspace iterator isolates failures per
workspace (one workspace failing
never affects others); within a workspace the runner records per-command
status and resumes on the
next run, and every command is idempotent, so partial runs self-heal.
### Supporting changes
* **Field-option color palette:** widened the `TagColor` union
(`twenty-shared` `FieldMetadataOptions`
+ the field-metadata `options.input` DTO) from 10 colors to the full
theme palette, benefiting any
future SELECT/MULTI_SELECT field.
* **Dev seeder:**
* The default "Annual Recurring Revenue" dashboard widget now points at
the generic
`annualRevenue` field (renamed to "Annual Revenue").
* Removed the "Companies by Size (Stacked by City)" widget (relied on
the demoted `employees`).
* `employees` is dropped from company data seeds and re-added as a
**custom** field seed, so dev
workspaces still get an `employees` column matching the demoted
behavior.
### Cleanup
Front-end record types (`Company.ts`/`Person.ts`), the
`getDisplayNameFromParticipant` test mock,
metadata integration specs, the Zapier `crud_record` test, and the
regenerated
`get-standard-object-metadata-related-entity-ids` snapshot.
## ⚠️ Breaking change (intentional)
Removes standard fields `Company.annualRecurringRevenue`,
`Company.employees`,
`Company.idealCustomerProfile`, `Company.xLink`, `Person.xLink`, and
`Person.city` from the core
GraphQL schema (replaced by `Company.annualRevenue`).
This is why the breaking-changes check reports a large number of
removals — `graphql-inspector`
flags any removed object field plus its derived
aggregate/order-by/filter/update types.
**Mitigation:** the
`upgrade:2-9:move-demoted-standard-fields-to-custom-application` command
re-owns these fields as custom fields per workspace, preserving their
name and data, so existing
tenants keep working. New workspaces won't have them.
## Summary
- Removes the deprecated `RICH_TEXT` (V1) field metadata type from the
codebase entirely
- Adds a 1.20 upgrade command that migrates existing `RICH_TEXT` fields
to `TEXT` in `core.fieldMetadata`
- Cleans up ~70 files across `twenty-shared`, `twenty-server`,
`twenty-front`, `twenty-sdk`, and `twenty-zapier`
## Context
`RICH_TEXT` was a legacy field type that stored rich text as a single
`text` column. It was already **read-only** — writes threw errors
directing users to `RICH_TEXT_V2` instead. `RICH_TEXT_V2` is the current
approach: a composite type with `blocknote` (editor JSON) and `markdown`
subfields. Keeping the deprecated type added maintenance burden without
any value.
Since the underlying database column type for `RICH_TEXT` was already
`text` (same as `TEXT`), the migration only needs to update the metadata
— no data migration or column changes required.
## Changes
### Upgrade command (new)
- `1-20-migrate-rich-text-to-text.command.ts` — runs `UPDATE
core."fieldMetadata" SET "type" = 'TEXT' WHERE "type" = 'RICH_TEXT'` per
workspace, with cache invalidation
### Enum & shared types
- Removed `RICH_TEXT` from `FieldMetadataType` enum
- Removed from `FieldMetadataDefaultValueMapping`,
`isFieldMetadataTextKind`
### Server (~30 files)
- Removed from type mapper (scalar, filter, order-by), data processors,
input transformer, filter operators, zod schemas, column type mapping,
searchable fields, RLS matching, OpenAPI schema, fake value generators
- Removed from field creation flow and field metadata type validator
- Updated dev seeder Pet `bio` field to `TEXT`
- Cleaned up mocks, snapshots, integration tests
### Frontend (~25 files)
- Deleted: `RichTextFieldDisplay`, `isFieldRichText`,
`isFieldRichTextValue`, `useRichTextFieldDisplay`
- Removed from `FieldDisplay`, `usePersistField`, `isFieldValueEmpty`,
`isRecordMatchingFilter`, `generateEmptyFieldValue`,
`isFieldCellSupported`, spreadsheet import, workflow fake values
- Removed from settings types, field type configs, and field creation
exclusion list
- Updated tests, mocks, and stories
### SDK & Zapier
- Removed from generated GraphQL schema and TypeScript types
- Removed from Zapier `computeInputFields`
## Summary
- **Merge queue optimization**: Created a dedicated
`ci-merge-queue.yaml` workflow that only runs Playwright E2E tests on
`ubuntu-latest-8-cores`. Removed `merge_group` trigger from all 7
existing CI workflows (front, server, shared, website, sdk, zapier,
docker-compose). The merge queue goes from ~30+ parallel jobs to a
single focused E2E job.
- **Label-based merge queue simulation**: Added `run-merge-queue` label
support so developers can trigger the exact merge queue E2E pipeline on
any open PR before it enters the queue.
- **Prettier in lint**: Chained `prettier --check` into `lint` and
`prettier --write` into `lint --configuration=fix` across `nx.json`
defaults, `twenty-front`, and `twenty-server`. Prettier formatting
errors are now caught by `lint` and fixed by `lint:fix` /
`lint:diff-with-main --configuration=fix`.
## After merge (manual repo settings)
Update GitHub branch protection required status checks:
1. Remove old per-workflow merge queue checks (`ci-front-status-check`,
`ci-e2e-status-check`, `ci-server-status-check`, etc.)
2. Add `ci-merge-queue-status-check` as the required check for the merge
queue
- Fixes self host application
- add new telemetry information
- add serverId to identify a server instance
- remove .twenty from git tracking
- tree-shake "twenty-sdk" usage in built logic functions and front
components
- fix "twenty-sdk" version usage
- fix twenty-zapier cli
---------
Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>
Resolves [Dependabot Alert
255](https://github.com/twentyhq/twenty/security/dependabot/255) - fix:
tmp allows arbitrary temporary file / directory write via symbolic link
`dir` parameter.
Updated the dev-dependency `zapier-platform-cli` for it to depend on tmp
0.2.4 and also ran `yarn up tmp --recursive` to update the version of
tmp elsewhere.
Not expecting any breaking changes to twenty-zapier since
`zapier-platform-cli` is marked as a development dependency.
Co-authored-by: martmull <martmull@hotmail.fr>
## Summary
Clean up and consolidate formatting configuration across the monorepo.
## Changes
### 1. Remove Redundant Configs
- ❌ Delete `packages/twenty-server/.prettierrc` (had invalid
`brakeBeforeElse` typo)
- ❌ Delete `packages/twenty-zapier/.prettierrc`
- ✅ Use root `.prettierrc` only (Prettier searches up directory tree
automatically)
### 2. Improve Root Prettier Config
- Change `endOfLine: 'auto'` → `'lf'` for consistent Unix line endings
across all OSes
### 3. Enhance VSCode Settings
- `files.eol: 'auto'` → `'\\n'` (consistent with Prettier)
- Add `files.insertFinalNewline: true` (explicit editor behavior)
- Add `files.trimTrailingWhitespace: true` (cleaner files)
### 4. Add `.gitattributes`
- Enforce LF line endings at Git level
- Prevents `core.autocrlf` from converting based on contributor's OS
- Mark patch files as binary (they have mixed line endings by design)
- Explicitly define binary file types
### 5. Fix Line Endings
- Convert 3 selectable-list state files from CRLF → LF
- These were the only source files with Windows line endings
## Why These Changes Matter
**Before:**
- 3 different Prettier configs (inconsistent, one had typo)
- Mixed CRLF/LF depending on contributor's OS
- No Git-level enforcement
**After:**
- Single source of truth for formatting
- All files use LF (Unix standard)
- Git enforces line endings regardless of OS
- Prettier warning about invalid option removed
## Result
- ✅ Single `.prettierrc` config
- ✅ Consistent LF line endings enforced by Git
- ✅ Better VSCode defaults
- ✅ No more CRLF files sneaking in from Windows contributors
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>
Changes the default behavior for settings navigation items to stay
active when navigating to sub-pages.
**Problem:**
- Navigation items like "Data Model" and "Webhooks" were not staying
highlighted when navigating to detail pages
- This was because `matchSubPages` defaulted to requiring exact path
matches
**Solution:**
- Updated logic to make sub-page matching the default behavior (`end:
item.matchSubPages === false`)
- Only "Accounts" explicitly sets `matchSubPages: false` for its custom
sub-item navigation
- Removed redundant `matchSubPages: true` declarations throughout the
codebase
**URL Changes:** -- checked with @Bonapara
- `/settings/workspace` → `/settings/general`
- `/settings/workspace-members` → `/settings/members`
- `/settings/api-keys` → `/settings/apis`
- `/settings/developers/webhooks` → `/settings/webhooks`
before:
https://github.com/user-attachments/assets/56b94a49-9c31-4bb5-9875-ec24f4bc4d1e
after:
https://github.com/user-attachments/assets/38742599-c045-44d1-8020-56f3eacca779
---------
Co-authored-by: Félix Malfait <felix.malfait@gmail.com>
# Introduction
In this PR we've migrated `twenty-shared` from a `vite` app
[libary-mode](https://vite.dev/guide/build#library-mode) to a
[preconstruct](https://preconstruct.tools/) "atomic" application ( in
the future would like to introduce preconstruct to handle of all our
atomic dependencies such as `twenty-emails` `twenty-ui` etc it will be
integrated at the monorepo's root directly, would be to invasive in the
first, starting incremental via `twenty-shared`)
For more information regarding the motivations please refer to nor:
- https://github.com/twentyhq/core-team-issues/issues/587
-
https://github.com/twentyhq/core-team-issues/issues/281#issuecomment-2630949682
close https://github.com/twentyhq/core-team-issues/issues/589
close https://github.com/twentyhq/core-team-issues/issues/590
## How to test
In order to ease the review this PR will ship all the codegen at the
very end, the actual meaning full diff is `+2,411 −114`
In order to migrate existing dependent packages to `twenty-shared` multi
barrel new arch you need to run in local:
```sh
yarn tsx packages/twenty-shared/scripts/migrateFromSingleToMultiBarrelImport.ts && \
npx nx run-many -t lint --fix -p twenty-front twenty-ui twenty-server twenty-emails twenty-shared twenty-zapier
```
Note that `migrateFromSingleToMultiBarrelImport` is idempotent, it's atm
included in the PR but should not be merged. ( such as codegen will be
added before merging this script will be removed )
## Misc
- related opened issue preconstruct
https://github.com/preconstruct/preconstruct/issues/617
## Closed related PR
- https://github.com/twentyhq/twenty/pull/11028
- https://github.com/twentyhq/twenty/pull/10993
- https://github.com/twentyhq/twenty/pull/10960
## Upcoming enhancement: ( in others dedicated PRs )
- 1/ refactor generate barrel to export atomic module instead of `*`
- 2/ generate barrel own package with several files and tests
- 3/ Migration twenty-ui the same way
- 4/ Use `preconstruct` at monorepo global level
## Conclusion
As always any suggestions are welcomed !
# Default address 🗺️ country & Phone ☎️ country
We add the ability to add a Default address country and a default Phone
country for fields in the Data model.
fix#8081
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
- fix webhook.operation format change from august 2024 not spread in
twenty-zapier
- added a comment so it does not happen again
- add a fix for the new webhook.operations column that would produce
another issue
Parship Chowdhury
