mirror of
https://github.com/twentyhq/twenty.git
synced 2026-04-18 05:54:42 -04:00
doc-restructuring
236 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
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.) |
||
|
Félix Malfait
|
245bd510ae |
chore: cleanup repository root structure (#17147)
## Summary This PR reduces clutter at the repository root to improve navigation on GitHub. The README is now visible much sooner when browsing the repo. ## Changes ### Deleted from root - `nx` wrapper script → use `npx nx` instead - `render.yaml` → no longer used - `jest.preset.js` → inlined `@nx/jest/preset` directly in each package's jest.config - `.prettierrc` → moved config to `package.json` - `.prettierignore` → patterns already covered by `.gitignore` ### Moved/Consolidated | From | To | |------|-----| | `Makefile` | `packages/twenty-docker/Makefile` (merged) | | `crowdin-app.yml` | `.github/crowdin-app.yml` | | `crowdin-docs.yml` | `.github/crowdin-docs.yml` | | `.vale.ini` | `.github/vale.ini` | | `tools/eslint-rules/` | `packages/twenty-eslint-rules/` | | `eslint.config.react.mjs` | `packages/twenty-front/eslint.config.react.mjs` | ## Result Root items reduced from ~32 to ~22 (folders + files). ## Files updated - GitHub workflow files updated to reference new crowdin config paths - Jest configs updated to use `@nx/jest/preset` directly - ESLint configs updated with new import paths - `nx.json` updated with new paths - `package.json` now includes prettier config and updated workspace paths - Dockerfile updated with new eslint-rules path |
||
|
Abdullah.
|
2c8d3f02e1 |
feat: upgrade to Storybook version 10 (#17110)
Upgraded to Storybook 10. We still use `@storybook/test-runner` for testing since it appears it'd require more work to move from Jest to Vitest than I initially anticipated, but I completed this PR to fix `storybook:serve:dev` - it takes time to load, but it works the way it used to with Storybook 8. https://github.com/user-attachments/assets/7afc32c6-4bcf-4b37-b83b-8d00d28dda15 |
||
|
Abdullah.
|
5240a1818f |
feat: upgrade Storybook to version 9 (#17077)
Upgraded from 8.6.15 to 9.1.17 in two steps: - 8.6.15 -> 9.0.0 - 9.0.0 -> 9.1.17 I had to disable `storybook-addon-cookie` since it is not supported for Storybook 9. However, I do intend to upgrade to Storybook 10 when this is merged, so we can replace the aforementioned add-on with this fork specifically created to support Storybook 10 and above: https://www.npmjs.com/package/@storybook-community/storybook-addon-cookie. Additionally, once we upgrade to Version 10 successfully, I will start looking into integrating the official Vitest add-on. |
||
|
Abdullah.
|
e83e616fde |
fix: qs's arrayLimit bypass in its bracket notation allows DoS via memory exhaustion (#16886)
Resolves [Dependabot Alert 354](https://github.com/twentyhq/twenty/security/dependabot/354) and [Dependabot Alert 355](https://github.com/twentyhq/twenty/security/dependabot/355). Upgraded express by one minor version. Removed redundant type definition in root `package.json` since we already have it in twenty-server's `package.json`. Upgraded body-parser patch version in serverless package.json. Co-authored-by: Félix Malfait <felix.malfait@gmail.com> |
||
|
Lucas Bordeau
|
0b5be7caa3 |
Refactored Date to Temporal in critical date zones (#16544)
Fixes https://github.com/twentyhq/twenty/issues/16110 This PR implements Temporal to replace the legacy Date object, in all features that are time zone sensitive. (around 80% of the app) Here we define a few utils to handle Temporal primitives and obtain an easier DX for timezone manipulation, front end and back end. This PR deactivates the usage of timezone from the graph configuration, because for now it's always UTC and is not really relevant, let's handle that later. Workflows code and backend only code that don't take user input are using UTC time zone, the affected utils have not been refactored yet because this PR is big enough. # New way of filtering on date intervals As we'll progressively rollup Temporal everywhere in the codebase and remove `Date` JS object everywhere possible, we'll use the way to filter that is recommended by Temporal. This way of filtering on date intervals involves half-open intervals, and is the preferred way to avoid edge-cases with DST and smallest time increment edge-case. ## Filtering endOfX with DST edge-cases Some day-light save time shifts involve having no existing hour, or even day on certain days, for example Samoa Islands have no 30th of December 2011 : https://www.timeanddate.com/news/time/samoa-dateline.html, it jumps from 29th to 31st, so filtering on `< next period start` makes it easier to let the date library handle the strict inferior comparison, than filtering on `≤ end of period` and trying to compute manually the end of the period. For example for Samoa Islands, is end of day `2011-12-29T23:59:59.999` or is it `2011-12-30T23:59:59.999` ? If you say I don't need to know and compute it, because I want everything strictly before `2011-12-29T00:00:00 + start of next day (according to the library which knows those edge-cases)`, then you have a 100% deterministic way of computing date intervals in any timezone, for any day of any year. Of course the Samoa example is an extreme one, but more common ones involve DST shifts of 1 hour, which are still problematic on certain days of the year. ## Computing the exact _end of period_ Having an open interval filtering, with `[included - included]` instead of half-open `[included - excluded)`, forces to compute the open end of an interval, which often involves taking an arbitrary unit like minute, second, microsecond or nanosecond, which will lead to edge-case of unhandled values. For example, let's say my code computes endOfDay by setting the time to `23:59:59.999`, if another library, API, or anything else, ends up giving me a date-time with another time precision `23:59:59.999999999` (down to the nanosecond), then this date-time will be filtered out, while it should not. The good deterministic way to avoid 100% of those complex bugs is to create a half-open filter : `≥ start of period` to `< start of next period` For example : `≥ 2025-01-01T00:00:00` to `< 2025-01-02T00:00:00` instead of `≥ 2025-01-01T00:00:00` to `≤ 2025-01-01T23:59:59.999` Because, `2025-01-01T00:00:00` = `2025-01-01T00:00:00.000` = `2025-01-01T00:00:00.000000` = `2025-01-01T00:00:00.000000000` => no risk of error in computing start of period But `2025-01-01T23:59:59` ≠ `2025-01-01T23:59:59.999` ≠ `2025-01-01T23:59:59.999999` ≠ `2025-01-01T23:59:59.999999999` => existing risk of error in computing end of period This is why an half-open interval has no risk of error in computing a date-time interval filter. Here is a link to this debate : https://github.com/tc39/proposal-temporal/issues/2568 > For this reason, we recommend not calculating the exact nanosecond at the end of the day if it's not absolutely necessary. For example, if it's needed for <= comparisons, we recommend just changing the comparison code. So instead of <= zdtEndOfDay your code could be < zdtStartOfNextDay which is easier to calculate and not subject to the issue of not knowing which unit is the right one. > > [Justin Grant](https://github.com/justingrant), top contributor of Temporal ## Application to our codebase Applying this half-open filtering paradigm to our codebase means we would have to rename `IS_AFTER` to `IS_AFTER_OR_EQUAL` and to keep `IS_BEFORE` (or even `IS_STRICTLY_BEFORE`) to make this half-open interval self-explanatory everywhere in the codebase, this will avoid any confusion. See the relevant issue : https://github.com/twentyhq/core-team-issues/issues/2010 In the mean time, we'll keep this operand and add this semantic in the naming everywhere possible. ## Example with a different user timezone Example on a graph grouped by week in timezone Pacific/Samoa, on a computer running on Europe/Paris : <img width="342" height="511" alt="image" src="https://github.com/user-attachments/assets/9e7d5121-ecc4-4233-835b-f59293fbd8c8" /> Then the associated data in the table view, with our **half-open date-time filter** : <img width="804" height="262" alt="image" src="https://github.com/user-attachments/assets/28efe1d7-d2fc-4aec-b521-bada7f980447" /> And the associated SQL query result to see how DATE_TRUNC in Postgres applies its internal start of week logic : <img width="709" height="220" alt="image" src="https://github.com/user-attachments/assets/4d0542e1-eaae-4b4b-afa9-5005f48ffdca" /> The associated SQL query without parameters to test in your SQL client : ```SQL SELECT "opportunity"."closeDate" as "close_date", TO_CHAR(DATE_TRUNC('week', "opportunity"."closeDate", 'Pacific/Samoa') AT TIME ZONE 'Pacific/Samoa', 'YYYY-MM-DD') AS "DATE_TRUNC by week start in timezone Pacific/Samoa", "opportunity"."name" FROM "workspace_1wgvd1injqtife6y4rvfbu3h5"."opportunity" "opportunity" ORDER BY "opportunity"."closeDate" ASC NULLS LAST ``` # Date picker simplification (not in this PR) Our DatePicker component, which is wrapping `react-datepicker` library component, is now exposing plain dates as string instead of Date object. The Date object is still used internally to manage the library component, but since the date picker calendar is only manipulating plain dates, there is no need to add timezone management to it, and no need to expose a handleChange with Date object. The timezone management relies on date time inputs now. The modification has been made in a previous PR : https://github.com/twentyhq/twenty/issues/15377 but it's good to reference it here. # Calendar feature refactor Calendar feature has been refactored to rely on Temporal.PlainDate as much as possible, while leaving some date-fns utils to avoid re-coding them. Since the trick is to use utils to convert back and from Date object in exec env reliably, we can do it everywhere we need to interface legacy Date object utils and Temporal related code. ## TimeZone is now shown on Calendar : <img width="894" height="958" alt="image" src="https://github.com/user-attachments/assets/231f8107-fad6-4786-b532-456692c20f1d" /> ## Month picker has been refactored <img width="503" height="266" alt="image" src="https://github.com/user-attachments/assets/cb90bc34-6c4d-436d-93bc-4b6fb00de7f5" /> Since the days weren't useful, the picker has been refactored to remove the days. # Miscellaneous - Fixed a bug with drag and drop edge-case with 2 items in a list. # Improvements ## Lots of chained operations It would be nice to create small utils to avoid repeated chained operations, but that is how Temporal is designed, a very small set of primitive operations that allow to compose everything needed. Maybe we'll have wrappers on top of Temporal in the coming years. ## Creation of Temporal objects is throwing errors If the input is badly formatted Temporal will throw, we might want to adopt a global strategy to avoid that. Example : ```ts const newPlainDate = Temporal.PlainDate.from('bad-string'); // Will throw ``` |
||
|
Abdullah.
|
ede261abf4 |
fix: storybook manager bundle may expose environment variables during build (#16747)
Resolves [Dependabot Alert 348](https://github.com/twentyhq/twenty/security/dependabot/348). Updated the patch version - 8.6.14 to 8.6.15. |
||
|
Abdullah.
|
1fcb8b464c |
fix: move vite plugins into the packages that use them (#16134)
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> |
||
|
martmull
|
e498367e2f |
Merge twenty-cli into twenty-sdk (#16150)
- Moves twenty-cli content into twenty-sdk - add a new twenty-sdk:0.1.0 version - this new twenty-sdk exports a cli command called 'twenty' (like twenty-cli before) - deprecates twenty-cli - simplify app init command base-project - use `twenty-sdk:0.1.0` in base project - move the "twenty-sdk/application" barrel to "twenty-sdk" - add `create-twenty-app` package <img width="1512" height="919" alt="image" src="https://github.com/user-attachments/assets/007bef45-4e71-419a-9213-cebed376adbf" /> <img width="1506" height="929" alt="image" src="https://github.com/user-attachments/assets/3de2fec6-1624-4923-ae13-f4e1cf165eb5" /> |
||
|
Abdullah.
|
978c0acb90 |
fix: sentry's sensitive headers are leaked when sendDefaultPii is set to true (#16122)
Resolves [Dependabot Alert 323](https://github.com/twentyhq/twenty/security/dependabot/323), [Dependabot Alert 324](https://github.com/twentyhq/twenty/security/dependabot/324) and [Dependabot Alert 325](https://github.com/twentyhq/twenty/security/dependabot/325). It updates Sentry's packages on the server from 10.21.0 to 10.27.0. I also moved @sentry/react to twenty-front package.json and updated the version from 9.26.0 to 10.27.0 - no breaking changes were introduced in the major upgrade in regards to the API exposed by the dependency. Since @sentry/profiling-node was redundant in the root package.json, I removed it - twenty-server has it already and is the only package dependent on @sentry/profiling-node. |
||
|
Abdullah.
|
d6d7f1bb20 |
fix: koa related dependabot alerts (#15868)
Resolves [Dependabot Alert 256](https://github.com/twentyhq/twenty/security/dependabot/256) and [Dependabot Alert 296](https://github.com/twentyhq/twenty/security/dependabot/296). This is a major bump for `nx` and related packages. Used the CLI to run nx migrations as recommended by the maintainers. Tested building, testing and linting packages after resetting the daemon, and did not come across a breaking issue. |
||
|
Abdullah.
|
7a68aa7f48 |
fix: playwright downloads and installs browsers without verifying the authenticity of the SSL certificate (#15843)
Resolves [Dependabot Alert 293](https://github.com/twentyhq/twenty/security/dependabot/293). Updates the playwright version used to `1.56.1`. The alert could have also been ignored since the playwright download only happens in CI and local environments, not the production environment. However, it's an easy fix instead of just ignoring the alert. |
||
|
Abdullah.
|
baa1a1e52f |
fix: babel vulnerable to arbitrary code execution when compiling specifically crafted malicious code (#15840)
Resolves [Dependabot Alert 95](https://github.com/twentyhq/twenty/security/dependabot/95) - babel vulnerable to arbitrary code execution when compiling specifically crafted malicious code. These were the few options we had for a direct drop-in replacement. - [x-var](https://www.npmjs.com/package/x-var?activeTab=readme) - [cross-let](https://www.npmjs.com/package/cross-let) - [cross-var-no-babel](https://www.npmjs.com/package/cross-var-no-babel) x-var has the most weekly downloads among the three and it is also the most actively maintained fork of the original cross-var package that introduced the vulnerability. There is no syntax difference per the documentation, but I do not have a windows machine to test. `cross-var-no-babel` offers the most minimal changes, but is also abandoned without a public-facing repo. |
||
|
Abdul Rahman
|
c0bae491e1 | docs: localize navigation tabs and groups for supported locales (#15811) | ||
|
Abdul Rahman
|
f740bac988 |
add documentation i18n workflows for Crowdin (#15538)
Co-authored-by: Félix Malfait <felix.malfait@gmail.com> Co-authored-by: Félix Malfait <felix@twenty.com> |
||
|
martmull
|
59f3f03539 |
Move browser-extension to proper folder (#15608)
As title - move all applications and browser extension into a `packages/twenty-apps/hacktoberfest-2025` folder |
||
|
Nabhag Motivaras
|
e09b67158e |
[HACKTOBERFEST] LINKEDIN EXTENSION (#15521)
# Twenty Browser Extension A Chrome browser extension for capturing LinkedIn profiles (people and companies) directly into Twenty CRM. This is a basic **v0** focused mostly on establishing a architectural foundation. ## Overview This extension integrates with LinkedIn to extract profile information and create records in Twenty CRM. It uses **WXT** as the framework - initially tried Plasmo, but found WXT to be significantly better due to its extensibility and closer alignment with the Chrome extension APIs, providing more control and flexibility. ## Architecture ### Package Structure The extension consists of two main packages: 1. **`twenty-browser-extension`** - The main extension package (WXT + React) 2. **`twenty-apps/browser-extension`** - Serverless functions for API interactions ### Extension Components #### Entrypoints - **Background Script** (`src/entrypoints/background/index.ts`) - Handles extension messaging protocol - Manages API calls to serverless functions - Coordinates communication between content scripts and popup - **Content Scripts** - **`add-person.content`** - Injects UI button on LinkedIn person profiles - **`add-company.content`** - Injects UI button on LinkedIn company profiles - Both scripts use WXT's `createIntegratedUi` for seamless DOM injection - Extract profile data from LinkedIn DOM - **Popup** (`src/entrypoints/popup/`) - React-based popup UI - Displays extracted profile information - Provides buttons to save person/company to Twenty #### Messaging System Uses `@webext-core/messaging` for type-safe communication between extension components: ```typescript // Defined in src/utils/messaging.ts - getPersonviaRelay() - Relays extraction from content script - getCompanyviaRelay() - Relays extraction from content script - extractPerson() - Extracts person data from LinkedIn DOM - extractCompany() - Extracts company data from LinkedIn DOM - createPerson() - Creates person record via serverless function - createCompany() - Creates company record via serverless function - openPopup() - Opens extension popup ``` #### Serverless Functions Located in `packages/twenty-apps/browser-extension/serverlessFunctions/`: - **`/s/create/person`** - Creates a new person record in Twenty - **`/s/create/company`** - Creates a new company record in Twenty - **`/s/get/person`** - Retrieves existing person record (placeholder) - **`/s/get/company`** - Retrieves existing company record (placeholder) ## Development Guide ### Prerequisites - Twenty CLI installed globally: `npm install -g twenty-cli` - API key from Twenty: https://twenty.com/settings/api-webhooks ### Setup ``` 1. **Configure environment variables:** - Set `TWENTY_API_URL` in the serverless function configuration - Set `TWENTY_API_KEY` (marked as secret) in the serverless function configuration - For local development, create a `.env` file or configure via `wxt.config.ts` ### Development Commands ```bash # Start development server with hot reload npx nx run dev twenty-browser-extension # Build for production npx nx run build twenty-browser-extension # Package extension for distribution npx nx run package twenty-browser-extension ``` ### Development Workflow 1. **Start the dev server:** ```bash npx nx run dev twenty-browser-extension ``` This starts WXT in development mode with hot module reloading. 2. **Load extension in Chrome:** - Navigate to `chrome://extensions/` - Enable "Developer mode" - Click "Load unpacked" - Select `packages/twenty-browser-extension/dist/chrome-mv3-dev/` 3. **Test on LinkedIn:** - Navigate to a LinkedIn person profile: `https://www.linkedin.com/in/...` - Navigate to a LinkedIn company profile: `https://www.linkedin.com/company/...` - The "Add to Twenty" button should appear in the profile header - Click the button to open the popup and save to Twenty ### Project Structure ``` packages/twenty-browser-extension/ ├── src/ │ ├── common/ │ │ └── constants/ # LinkedIn URL patterns │ ├── entrypoints/ │ │ ├── background/ # Background service worker │ │ ├── popup/ # Extension popup UI │ │ ├── add-person.content/ # Content script for person profiles │ │ └── add-company.content/ # Content script for company profiles │ ├── ui/ # Shared UI components and theme │ └── utils/ # Messaging utilities ├── public/ # Static assets (icons) ├── wxt.config.ts # WXT configuration └── project.json # Nx project configuration ``` ## Current Status (v0) This is a foundational version focused on architecture. Current features: ✅ Inject UI buttons into LinkedIn profiles ✅ Extract person and company data from LinkedIn ✅ Display extracted data in popup ✅ Create person records in Twenty ✅ Create company records in Twenty ## Planned Features - [ ] Provide a way to have API key and custom remote URLs. - [ ] Detect if record already exists and prevent duplicates - [ ] Open existing Twenty record when clicked (instead of creating duplicate) - [ ] Sidepanel Overlay UI for rich profile viewing/editing - [ ] Enhanced data extraction (email, phone, etc.) - [ ] Better error handling # Demo https://github.com/user-attachments/assets/0bbed724-a429-4af0-a0f1-fdad6997685e https://github.com/user-attachments/assets/85d2301d-19ee-43ba-b7f9-13ed3915f676 |
||
|
Lucas Bordeau
|
afeb505eed |
[Breaking Change] Implement reliable date picker utils to handle all timezone combinations (#15377)
This PR implements the necessary tools to have `react-datepicker` calendar and our date picker components work reliably no matter the timezone difference between the user execution environment and the user application timezone. Fixes https://github.com/twentyhq/core-team-issues/issues/1781 This PR won't cover everything needed to have Twenty handle timezone properly, here is the follow-up issue : https://github.com/twentyhq/core-team-issues/issues/1807 # Features in this PR This PR brings a lot of features that have to be merged together. - DATE field type is now handled as string only, because it shouldn't involve timezone nor the JS Date object at all, since it is a day like a birthday date, and not an absolute point in time. - DATE_TIME field wasn't properly handled when the user settings timezone was different from the system one - A timezone abbreviation suffix has been added to most DATE_TIME display component, only when the timezone is different from the system one in the settings. - A lot of bugs, small features and improvements have been made here : https://github.com/twentyhq/core-team-issues/issues/1781 # Handling of timezones ## Essential concepts This topic is so complex and easy to misunderstand that it is necessary to define the precise terms and concepts first. It resembles character encoding and should be treated with the same care. - Wall-clock time : the time expressed in the timezone of a user, it is distinct from the absolute point in time it points to, much like a pointer being a different value than the value that it points to. - Absolute time : a point in time, regardless of the timezone, it is an objective point in time, of course it has to be expressed in a given timezone, because we have to talk about when it is located in time between humans, but it is in fact distinct from any wall clock time, it exists in itself without any clock running on earth. However, by convention the low-level way to store an absolute point in time is in UTC, which is a timezone, because there is no way to store an absolute point in time without a referential, much like a point in space cannot be stored without a referential. - DST : Daylight Save Time, makes the timezone shift in a specific period every year in a given timezone, to make better use of longer days for various reasons, not all timezones have DST. DST can be 1 hour or 30 min, 45 min, which makes computation difficult. - UTC : It is NOT an “absolute timezone”, it is the wall-clock time at 0° longitude without DST, which is an arbitrary and shared human convention. UTC is often used as the standard reference wall-clock time for talking about absolute point in time without having to do timezone and DST arithmetic. PostgreSQL stores everything in UTC by convention, but outputs everything in the server’s SESSION TIMEZONE. ## How should an absolute point in time be stored ? Since an absolute point in time is essentially distinct from its timezone it could be stored in an absolute way, but in practice it is impossible to store an absolute point in time without a referential. We have to say that a rocket launched at X given time, in UTC, EST, CET, etc. And of course, someone in China will say that it launched at 10:30, while in San Francisco it will have launched at 19:30, but it is THE SAME absolute point in time. Let’s take a related example in computer science with character encoding. If a text is stored without the associated encoding table, the correct meaning associated to the bits stored in memory can be lost forever. It can become impossible for a program to guess what encoding table should be used for a given text stored as bits, thus the glitches that appeared a lot back in the early days of internet and document processing. The same can happen with date time storing, if we don’t have the timezone associated with the absolute point in time, the information of when it absolutely happened is lost. It is NOT necessary to store an absolute point in time in UTC, it is more of a standard and practical wall-clock time to be associated with an absolute point in time. But an absolute point in time MUST be store with a timezone, with its time referential, otherwise the information of when it absolutely happened is lost. For example, it is easier to pass around a date as a string in UTC, like `2024-01-02T00:00:00Z` because it allows front-end and back-end code to “talk” in the same standard and DST-free wall-clock time, BUT it is not necessary. Because we have date libraries that operate on the standard ISO timezone tables, we can talk in different timezone and let the libraries handle the conversion internally. It is false to say that UTC is an absolute timezone or an absolute point in time, it is just the standard, conventional time referential, because one can perfectly store every absolute points in time in UTC+10 with a complex DST table and have the exactly correct absolute points in time, without any loss of information, without having any UTC+0 dates involved. Thus storing an absolute point in time without a timezone associated, for example with `timestamp` PostgreSQL data type, is equivalent to storing a wall-clock time and then throwing away voluntarily the information that allows to know when it absolutely happened, which is a voluntary data-loss if the code that stores and retrieves those wall-clock points in time don’t store the associated timezone somewhere. This is why we use `timestamptz` type in PostgreSQL, so that we make sure that the correct absolute point in time is stored at the exact time we send it to PostgreSQL server, no matter the front-end, back-end and SQL server's timezone differences. ## The JavaScript Date object The native JavaScript Date object is now officially considered legacy ([source](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date)), the Date object stores an absolute point in time BUT it forces the storage to use its execution environment timezone, and one CANNOT modify this timezone, this is a legacy behavior. To obtain the desired result and store an absolute point in time with an arbitrary timezone there are several options : - The new Temporal API that is the successor of the legacy Date object. - Moment / Luxon / @date-fns/tz that expose objects that allow to use any timezone to store an absolute point in time. ## How PostgreSQL stores absolute point in times PostgreSQL stores absolute points in time internally in UTC ([source](https://www.postgresql.org/docs/current/datatype-datetime.html#DATATYPE-DATETIME-INPUT-TIME-STAMPS)), but the output date is expressed in the server’s session timezone ([source](https://www.postgresql.org/docs/current/sql-set.html)) which can be different from UTC. Example with the object companies in Twenty seed database, on a local instance, with a new “datetime” custom column : <img width="374" height="554" alt="image" src="https://github.com/user-attachments/assets/4394cb43-d97e-4479-801d-ca068f800e39" /> <img width="516" height="524" alt="image" src="https://github.com/user-attachments/assets/b652f36a-d2e2-47a4-8950-647ca688cbbd" /> ## Why can’t I just use the JavaScript native Date object with some manual logic ? Because the JavaScript Date object does not allow to change its internal timezone, the libraries that are based on it will behave on the execution environment timezone, thus leading to bugs that appear only on the computers of users in a timezone but not for other in another timezone. In our case the `react-datepicker` library forces to use the `Date` object, thus forcing the calendar to behave in the execution environment system timezone, which causes a lot of problems when we decide to display the Twenty application DATE_TIME values in another timezone than the user system one, the bugs that appear will be of the off-by-one date class, for example clicking on 23 will select 24, thus creating an unreliable feature for some system / application timezone combinations. A solution could be to manually compute the difference of minutes between the application user and the system timezones, but that’s not reliable because of DST which makes this computation unreliable when DST are applied at different period of the year for the two timezones. ## Why can’t I compute the timezone difference manually ? Because of DST, the work to compute the timezone difference reliably, not just for the usual happy path, is equivalent to developing the internal mechanism of a date timezone library, which is equivalent to use a library that handles timezones. ## Using `@date-fns/tz` to solve this problem We could have used `luxon` but it has a heavy bundle size, so instead we rely here on `@date-fns/tz` (~1kB) which gives us a `TZDate` object that allows to use any given timezone to store an absolute point-in-time. The solution here is to trick `react-datepicker` by shifting a Date object by the difference of timezone between the user application timezone and the system timezone. Let’s take a concerte example. System timezone : Midway, ⇒ UTC-11:00, has no DST. User application timezone : Auckland, NZ ⇒ UTC+13:00, has a DST. We’ll take the NZ daylight time, so that will make a timezone difference of 24 hours ! Let’s take an error-prone date : `2025-01-01T00:00:00` . This date is usually a good test-case because it can generate three classes of bugs : off-by-one day bugs, off-by-one month bugs and off-by-one year bugs, at the same time. Here is the absolute point in time we take expressed in the different wall-clock time points we manipulate Case | In system timezone ⇒ UTC-11 | In UTC | In user application timezone ⇒ UTC+13 -- | -- | -- | -- Original date | `2024-12-31T00:00:00-11:00` | `2024-12-31T11:00:00Z` | `2025-01-01T00:00:00+13:00` Date shifted for react-datepicker | `2025-01-01T00:00:00-11:00` | `2025-01-01T11:00:00Z` | `2025-01-02T00:00:00+13:00` We can see with this table that we have the number part of the date that is the same (`2025-01-01T00:00:00`) but with a different timezone to “trick” `react-datepicker` and have it display the correct day in its calendar. You can find the code in the hooks `useTurnPointInTimeIntoReactDatePickerShiftedDate` and `useTurnReactDatePickerShiftedDateBackIntoPointInTime` that contain the logic that produces the above table internally. ## Miscellaneous Removed FormDateFieldInput and FormDateTimeFieldInput stories as they do not behave the same depending of the execution environment and it would be easier to put them back after having refactored FormDateFieldInput and FormDateTimeFieldInput --------- Co-authored-by: Charles Bochet <charles@twenty.com> |
||
|
Abdul Rahman
|
2c39fc04c2 | feat: Migrate documentation to Mintlify and implement Helper Agent with search functionality (#15443) | ||
|
Abdullah.
|
f367bd6072 |
fix: vite related dependabot alerts (#15464)
Resolves [14 Dependabot Alerts](https://github.com/twentyhq/twenty/security/dependabot?q=is%3Aopen+package%3Avite+manifest%3Ayarn.lock+has%3Apatch) simultaneously. Vitest 1.4.0 was imported in root package.json, which further imported Vite 5. However, Vitest solved no purpose at the moment since we still rely on Jest for testing. Therefore, removed the package and we can import the latest 4x version when we move from Jest to Vitest. For the rest of the use-cases of Vite, ran `yarn up vite --recursive` for the version used to be greater than 7.0.8. <p align="center"> <img width="403" height="132" alt="image" src="https://github.com/user-attachments/assets/a4ff7a75-2e3f-4dea-9f40-9cfdf07d6252" /> </p> |
||
|
Raphaël Bosi
|
198bf5a333 |
Complete color refactoring (#15414)
# Complete color refactoring Closes https://github.com/twentyhq/core-team-issues/issues/1779 - Updated all colors to use Radix colors with P3 color space allowing for brighter colors - Created our own gray scale interpolated on Radix's scale to have the same values for grays as the old ones in the app - Introduced dark and light colors as well as there transparent versions - Added many new colors from radix that can be used in the tags or in the graphs - Updated multiple color utilities to match new behaviors - Changed the computation of Avatar colors to return only colors from the theme (before it was random hsl) These changes allow the user to use new colors in tags or charts, the colors are brighter and with better contrast. We have a full range of color variations from 1 to 12 where before we only had 4 adaptative colors. All these changes will allow us to develop custom themes for the user soon, where users can choose their accent colors, background colors and there contrast. |
||
|
Abdullah.
|
63c261645a |
fix: nodemailer - email to an unintended domain can occur due to interpretation conflict. (#15356)
Resolves [Dependabot Alert 289](https://github.com/twentyhq/twenty/security/dependabot/289) and a couple other alerts. Removed types for `imapflow` since the package ships them internally now. `yarn.lock` has major changes due to an upgraded AWS SDK `@aws-sdk/client-sesv2` which is used by Nodemailer 7. - No breaking changes were introduced in imapflow and mailparser. - Nodemailer's breaking change was dropping the legacy SES transport; we already use the SMTP transport + our own AWS SES client, so nothing else needs changing. |
||
|
Abdullah.
|
f7a80d250b |
Update dizzle-kit and drizzle-orm to avoid the dependency on Hono. (#15343)
Updated both drizzle-kit and drizzle-orm to the latest versions. Process: - Ran migrations on the database. - Updated the versions. - Made the required changes to `drizzle-posgres.config.ts`. - Ensured migrations are not out of sync be running them again - no issues, no updates applied. - Updated the snapshots. - Deleted the database named `website`. - Re-ran the migrations to confirm. There are no breaking changes because the surface drizzle-orm covers is limited. However, we had to update drizzle-orm in order to update drizzle-kit to a version greater than 0.27.0 in order to avoid the use of hono. Therefore, I went ahead and updated both to the latest. Resolves [Dependabot Alert #274](https://github.com/twentyhq/twenty/security/dependabot/274) and three others. |
||
|
Abdullah.
|
1120107b34 |
Remove unused dependencies from root package.json. (#15323)
These removed dependencies are not being imported anywhere in the code base. Both `twenty-server` and `twenty-front` build properly, ensuring the dependent packages like `twenty-emails`, `twenty-ui`, `twenty-shared` etc are building properly. |