Elgato_dark/twenty
1
0
Fork 0
mirror of https://github.com/twentyhq/twenty synced 2026-04-21 13:37:22 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 17
twenty/nx.json

306 lines
8.8 KiB
JSON
Raw Permalink Normal View History

Migrate to a monorepo structure (#2909)
2023-12-10 17:10:54 +00:00
{
Refactor usePersistField (#13775) This PR introduces refactors and tradeoffs in the API around the events of field input. # Refactored usePersistField The hook `usePersistField` has been refactored to be used anywhere in the app, not just inside a FieldContext. This was meant to solve a bug at the beginning but now it is just used once in `RecordDetailRelationSection` outside of the context, still this is better to have this hook like that for future use cases. We also introduce `usePersistFieldFromFieldInputContext`, for an easier API inside a FieldContext. # Introduced a new `FieldInputEventContext` To remove the drill-down of events, we introduce `FieldInputEventContext`, this allows to set only once the handlers / events. In practice it allows to have an easier time maintaining the events for the many different field inputs, because it matches the pattern we already use of taking everything from a context (`FieldContext`). # Removed drill-down from FieldInput The heavy drill-down in FieldInput has been completely removed, since everything can be derived from `FieldContext` and `FieldInputEventContext`. Also there was some readonly and other specific props, but they were all drilled down from FieldContext, so it was easier to just use FieldContext where needed. # Refactored events of `MultiItemFieldInputProps` The component `MultiItemFieldInputProps` has a contrived API, here we just remove the complex part that was persisting from inside. We now only give a classic API with `onChange` and `onEscape` the rest is left to higher levels, where it should be, because this generic component shouldn't be aware of persisting things. # Extracted the parsing logic of persisted values For each input field component, we now have a clear util that was before bound to the persist call, # Tradeoff with persist times The tradeoff before was that persistField was called anywhere, before exiting the component sometimes, now it is only called by the higher levels like table or show page, which handles this abstraction. This could be challenged, however I think that having a lot of different events, and not just `handleSubmit` and `handleCancel`, convey enough meaning for the higher levels to decide what to do in each case. A `skipPersist` argument was added in events in the rare edge cases where we want to voluntarily skip persisting even with a submit or escape, but that could be challenged because we could also say that we should use cancel for that and stick to that convention. # Handling of the bug in `ActivityRichTextEditor` Initially this refactor was prioritized for solving this bug, which was very annoying for the users. But while fixing it with the new persistField hook I just understood that the problem is not just for record title cells but for anything that is open when we click on a rich text editor. The issue is described here : https://github.com/twentyhq/core-team-issues/issues/1317 So right now I just let it as is. # Stories The stories were checking that a request was sent in some cases where persist was called before a component exiting, now that persist is only called by higher-levels I just removed those tests from the stories, because that should be the responsibility of higher levels. Also a helper `getFieldInputEventContextProviderWithJestMocks` was created that exposes a context and jest mock functions for testing this new API in stories. # Miscellaneous Deactivated tui with nx by default, because it can be annoying.
2025-08-12 08:42:13 +00:00
"workspaceLayout": {
"appsDir": "packages",
"libsDir": "packages"
},
chore: use Nx affected tasks in CI (#5110) Closes #5097 - Uses "nx affected" to detect what projects need to be checked in the current PR (for now, `ci-front` and `ci-server` workflows only). - Caches results of certain tasks (`lint`, `typecheck`, `test`, `storybook:build`) when a PR pipeline runs. The next runs of the same PR's pipeline will then be able to reuse the PR's task cache to execute tasks faster. - Caches Yarn's cache folder to install dependencies faster in CI jobs. - Rewrites the node modules cache/install steps as a custom, reusable Github action. - Distributes `ci-front` jobs with a "matrix" strategy. - Sets common tasks config at the root `nx.json`. For instance, to activate the `typecheck` task in a project, add `typecheck: {}` to its `project.json` and it'll use the default config set in `nx.json` for the `typecheck` task. Options can be overridden in each individual `project.json` if needed. - Adds "scope" tags to some projects: `scope:frontend`, `scope:backend`, `scope:shared`. An eslint rule ensures that `scope:frontend` only depends on `scope:frontent` or `scope:shared` projects, same for `scope:backend`. These tags are used by `nx affected` to filter projects by scope and generates different task cache keys according to the requested scope. - Enables checks for twenty-emails in the `ci-server` workflow.
2024-04-30 14:28:25 +00:00
"namedInputs": {
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.)
2026-01-17 06:37:17 +00:00
"default": ["{projectRoot}/**/*"],
fix: fix storybook coverage task (#5256) - Fixes storybook coverage command: the coverage directory path was incorrect, but instead of failing `storybook:test --configuration=ci`, it was hanging indefinitely. - Switches back to `concurrently` to launch `storybook:static` and `storybook:test` in parallel, which allows to use options to explicitly kill `storybook:static` when `storybook:test` fails. - Moves `storybook:test --configuration=ci` to its own command `storybook:static:test`: used in the CI, and can be used locally to run storybook tests without having to launch `storybook:dev` first. - Creates command `storybook:coverage` and enables cache for this command. - Fixes Jest tests that were failing. - Improves caching conditions for some tasks (for instance, no need to invalidate Jest test cache if only Storybook story files were modified).
2024-05-03 12:59:09 +00:00
"excludeStories": [
"default",
"!{projectRoot}/.storybook/*",
"!{projectRoot}/**/tsconfig.storybook.json",
"!{projectRoot}/**/*.stories.(ts|tsx)",
"!{projectRoot}/**/__stories__/*"
],
"excludeTests": [
"default",
"!{projectRoot}/**/jest.config.(js|ts)",
"!{projectRoot}/**/tsconfig.spec.json",
"!{projectRoot}/**/*.test.(ts|tsx)",
"!{projectRoot}/**/*.spec.(ts|tsx)",
Add Integration and unit tests on Billing (#9317) Solves [ https://github.com/twentyhq/private-issues/issues/214 ] **TLDR** Add unit and integration tests to Billing. First approach to run jest integration tests directly from VSCode. **In order to run the unit tests:** Run unit test using the CLI or with the jest extension directly from VSCode. **In order to run the integration tests:** Ensure that your database has the billingTables. If that's not the case, migrate the database with IS_BILLING_ENABLED set to true: ` npx nx run twenty-server:test:integration test/integration/billing/suites/billing-controller.integration-spec.ts` **Doing:** - Unit test on transformSubscriptionEventToSubscriptionItem - More tests cases in billingController integration tests. --------- Co-authored-by: Félix Malfait <felix.malfait@gmail.com> Co-authored-by: Weiko <corentin@twenty.com> Co-authored-by: Charles Bochet <charlesBochet@users.noreply.github.com>
2025-01-09 17:30:41 +00:00
"!{projectRoot}/**/*.integration-spec.ts",
fix: fix storybook coverage task (#5256) - Fixes storybook coverage command: the coverage directory path was incorrect, but instead of failing `storybook:test --configuration=ci`, it was hanging indefinitely. - Switches back to `concurrently` to launch `storybook:static` and `storybook:test` in parallel, which allows to use options to explicitly kill `storybook:static` when `storybook:test` fails. - Moves `storybook:test --configuration=ci` to its own command `storybook:static:test`: used in the CI, and can be used locally to run storybook tests without having to launch `storybook:dev` first. - Creates command `storybook:coverage` and enables cache for this command. - Fixes Jest tests that were failing. - Improves caching conditions for some tasks (for instance, no need to invalidate Jest test cache if only Storybook story files were modified).
2024-05-03 12:59:09 +00:00
"!{projectRoot}/**/__tests__/*"
],
"production": [
"default",
"excludeStories",
"excludeTests",
"!{projectRoot}/**/__mocks__/*",
"!{projectRoot}/**/testing/*"
]
chore: use Nx affected tasks in CI (#5110) Closes #5097 - Uses "nx affected" to detect what projects need to be checked in the current PR (for now, `ci-front` and `ci-server` workflows only). - Caches results of certain tasks (`lint`, `typecheck`, `test`, `storybook:build`) when a PR pipeline runs. The next runs of the same PR's pipeline will then be able to reuse the PR's task cache to execute tasks faster. - Caches Yarn's cache folder to install dependencies faster in CI jobs. - Rewrites the node modules cache/install steps as a custom, reusable Github action. - Distributes `ci-front` jobs with a "matrix" strategy. - Sets common tasks config at the root `nx.json`. For instance, to activate the `typecheck` task in a project, add `typecheck: {}` to its `project.json` and it'll use the default config set in `nx.json` for the `typecheck` task. Options can be overridden in each individual `project.json` if needed. - Adds "scope" tags to some projects: `scope:frontend`, `scope:backend`, `scope:shared`. An eslint rule ensures that `scope:frontend` only depends on `scope:frontent` or `scope:shared` projects, same for `scope:backend`. These tags are used by `nx affected` to filter projects by scope and generates different task cache keys according to the requested scope. - Enables checks for twenty-emails in the `ci-server` workflow.
2024-04-30 14:28:25 +00:00
},
Migrate to a monorepo structure (#2909)
2023-12-10 17:10:54 +00:00
"targetDefaults": {
"build": {
"cache": true,
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.)
2026-01-17 06:37:17 +00:00
"inputs": ["^production", "production"],
"dependsOn": ["^build"]
Refactor usePersistField (#13775) This PR introduces refactors and tradeoffs in the API around the events of field input. # Refactored usePersistField The hook `usePersistField` has been refactored to be used anywhere in the app, not just inside a FieldContext. This was meant to solve a bug at the beginning but now it is just used once in `RecordDetailRelationSection` outside of the context, still this is better to have this hook like that for future use cases. We also introduce `usePersistFieldFromFieldInputContext`, for an easier API inside a FieldContext. # Introduced a new `FieldInputEventContext` To remove the drill-down of events, we introduce `FieldInputEventContext`, this allows to set only once the handlers / events. In practice it allows to have an easier time maintaining the events for the many different field inputs, because it matches the pattern we already use of taking everything from a context (`FieldContext`). # Removed drill-down from FieldInput The heavy drill-down in FieldInput has been completely removed, since everything can be derived from `FieldContext` and `FieldInputEventContext`. Also there was some readonly and other specific props, but they were all drilled down from FieldContext, so it was easier to just use FieldContext where needed. # Refactored events of `MultiItemFieldInputProps` The component `MultiItemFieldInputProps` has a contrived API, here we just remove the complex part that was persisting from inside. We now only give a classic API with `onChange` and `onEscape` the rest is left to higher levels, where it should be, because this generic component shouldn't be aware of persisting things. # Extracted the parsing logic of persisted values For each input field component, we now have a clear util that was before bound to the persist call, # Tradeoff with persist times The tradeoff before was that persistField was called anywhere, before exiting the component sometimes, now it is only called by the higher levels like table or show page, which handles this abstraction. This could be challenged, however I think that having a lot of different events, and not just `handleSubmit` and `handleCancel`, convey enough meaning for the higher levels to decide what to do in each case. A `skipPersist` argument was added in events in the rare edge cases where we want to voluntarily skip persisting even with a submit or escape, but that could be challenged because we could also say that we should use cancel for that and stick to that convention. # Handling of the bug in `ActivityRichTextEditor` Initially this refactor was prioritized for solving this bug, which was very annoying for the users. But while fixing it with the new persistField hook I just understood that the problem is not just for record title cells but for anything that is open when we click on a rich text editor. The issue is described here : https://github.com/twentyhq/core-team-issues/issues/1317 So right now I just let it as is. # Stories The stories were checking that a request was sent in some cases where persist was called before a component exiting, now that persist is only called by higher-levels I just removed those tests from the stories, because that should be the responsibility of higher levels. Also a helper `getFieldInputEventContextProviderWithJestMocks` was created that exposes a context and jest mock functions for testing this new API in stories. # Miscellaneous Deactivated tui with nx by default, because it can be annoying.
2025-08-12 08:42:13 +00:00
},
"start": {
Upgrade NestJS from 10.x to 11.x (#15836) ## Overview This PR upgrades all NestJS dependencies from version 10.x to 11.x, following the [official migration guide](https://docs.nestjs.com/migration-guide). This builds on top of the v9 to v10 upgrade completed in PR #15835. ## Changes ### Dependencies Updated **Core packages (10.x → 11.x):** - `@nestjs/common`: 10.4.16 → 11.0.8 - `@nestjs/core`: 10.4.16 → 11.0.8 - `@nestjs/platform-express`: 10.4.16 → 11.0.8 - `@nestjs/config`: 3.2.3 → 3.3.0 - `@nestjs/passport`: 10.0.3 → 11.0.0 - `@nestjs/axios`: 3.0.2 → 3.1.2 - `@nestjs/schedule`: ^3.0.0 → ^4.1.1 - `@nestjs/serve-static`: 4.0.2 → 5.0.1 - `@nestjs/cache-manager`: ^2.2.1 → ^2.3.0 - `@nestjs/jwt`: 10.2.0 → 11.0.0 - `@nestjs/typeorm`: 10.0.2 → 11.0.0 - `@nestjs/terminus`: 11.0.0 (already on v11) - `@nestjs/event-emitter`: 2.1.0 (compatible) **DevDependencies:** - `@nestjs/testing`: ^10.4.16 → ^11.0.8 - `@nestjs/schematics`: ^10.1.0 → ^11.0.2 - `@nestjs/cli`: 10.3.0 → 11.0.0 ### Code Changes **Fixed: TwentyConfigModule conditional imports** - Updated `TwentyConfigModule.forRoot()` to use spread operator for conditional imports - Fixes TypeScript error with NestJS 11's stricter DynamicModule type checking **Cleanup: Removed unused package** - Removed `@revertdotdev/revert-react` (not being used anywhere in the codebase) ## Breaking Changes Addressed ### 1. ✅ Reflector Type Inference - **Impact**: None - codebase only uses `reflector.get()` method - **Analysis**: Does not use `getAllAndMerge()` or `getAllAndOverride()` (the methods with breaking changes) - **Files reviewed**: feature-flag.guard.ts, message-queue-metadata.accessor.ts, workspace-query-hook-metadata.accessor.ts ### 2. ✅ Lifecycle Hooks Execution Order - **Change**: Termination hooks (`OnModuleDestroy`, `BeforeApplicationShutdown`, `OnApplicationShutdown`) now execute in REVERSE order - **Analysis**: Reviewed all lifecycle hook implementations - Redis client cleanup - Database connection cleanup (GlobalWorkspaceDataSource) - BullMQ queue/worker cleanup - Cache storage cleanup - **Result**: Dependency order is safe - services using connections clean up before the connections themselves ### 3. ✅ Middleware Registration Order - **Change**: Global middleware now executes first regardless of import order - **Analysis**: Middleware is not registered as global, so execution order remains consistent - **Files reviewed**: app.module.ts, middleware.module.ts ## Testing All tests passing and build successful: **Unit Tests (283+ tests):** - ✅ Health module: 38 tests passed - ✅ Auth module: 115 tests passed (passport v11 integration) - ✅ REST API: 90 tests passed (middleware and express platform) - ✅ Feature flags: 17 tests passed (Reflector usage) - ✅ Workspace: 23 tests passed **Build & Quality:** - ✅ Type checking: Passed - ✅ Linting: Passed - ✅ Build: 3,683 files compiled successfully ## Verification Tested critical NestJS functionality: - ✅ Authentication & Security (JWT, OAuth, guards) - ✅ HTTP Platform (Express integration, REST endpoints) - ✅ Dependency Injection (Services, factories, providers) - ✅ Cache Management (Redis with @nestjs/cache-manager) - ✅ GraphQL (Query runners, resolvers) - ✅ Configuration (Environment config) - ✅ Scheduling (Cron jobs with @nestjs/schedule v4) - ✅ Lifecycle Hooks (Module initialization and cleanup) - ✅ Reflector (Metadata reflection in guards) ## Related PRs - #15835 - Upgrade NestJS from 9.x to 10.x (completed) <!-- CURSOR_SUMMARY --> --- > [!NOTE] > Upgrades NestJS to v11 and updates routing patterns, auth strategies, GraphQL schema options, and build/dist paths (scripts, Docker, Nx, migrations, assets), plus enables Devtools in development. > > - **Backend (NestJS 11 upgrade)**: > - Bump `@nestjs/*` packages (core, platform-express, jwt, passport, typeorm, serve-static, schedule, cli/testing/schematics) to v11. > - Update REST/route-trigger/file controllers to new wildcard syntax (`*path`). > - Refactor OAuth (Google/Microsoft) and SAML strategies (abstract base + explicit `validate`); minor typings. > - Enable `DevtoolsModule` in development. > - **GraphQL**: > - Add `buildSchemaOptions.orphanedTypes` for client-config types; keep Yoga/Sentry setup. > - **Build/Runtime & Config**: > - Standardize dist layout (remove `src` in paths): update scripts, Docker `CMD`, Nx `project.json`, render scripts, TypeORM migration paths, asset resolution. > - Adjust `nest-cli.json` (watchOptions, asset globs, migrations outDir, monorepo/root). > - Improve config module imports (spread conditional); tsconfig excludes `node_modules`. > - Minor Nx default: `start` target caching disabled. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 1139fd85a97d0c72314d416d07464cc3c9942783. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY -->
2025-11-16 17:20:06 +00:00
"cache": false,
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.)
2026-01-17 06:37:17 +00:00
"dependsOn": ["^build"]
Migrate to a monorepo structure (#2909)
2023-12-10 17:10:54 +00:00
},
"lint": {
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
2026-03-06 00:03:50 +00:00
"executor": "nx:run-commands",
chore: use Nx affected tasks in CI (#5110) Closes #5097 - Uses "nx affected" to detect what projects need to be checked in the current PR (for now, `ci-front` and `ci-server` workflows only). - Caches results of certain tasks (`lint`, `typecheck`, `test`, `storybook:build`) when a PR pipeline runs. The next runs of the same PR's pipeline will then be able to reuse the PR's task cache to execute tasks faster. - Caches Yarn's cache folder to install dependencies faster in CI jobs. - Rewrites the node modules cache/install steps as a custom, reusable Github action. - Distributes `ci-front` jobs with a "matrix" strategy. - Sets common tasks config at the root `nx.json`. For instance, to activate the `typecheck` task in a project, add `typecheck: {}` to its `project.json` and it'll use the default config set in `nx.json` for the `typecheck` task. Options can be overridden in each individual `project.json` if needed. - Adds "scope" tags to some projects: `scope:frontend`, `scope:backend`, `scope:shared`. An eslint rule ensures that `scope:frontend` only depends on `scope:frontent` or `scope:shared` projects, same for `scope:backend`. These tags are used by `nx affected` to filter projects by scope and generates different task cache keys according to the requested scope. - Enables checks for twenty-emails in the `ci-server` workflow.
2024-04-30 14:28:25 +00:00
"cache": true,
"options": {
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
2026-03-06 00:03:50 +00:00
"cwd": "{projectRoot}",
Optimize merge queue to only run E2E and integrate prettier into lint (#18459) ## 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
2026-03-06 12:20:57 +00:00
"command": "npx oxlint -c .oxlintrc.json . && (prettier . --check --cache --cache-location ../../.cache/prettier/{projectRoot} --cache-strategy metadata || (echo 'ERROR: Prettier formatting check failed! Fix with: npx nx lint --configuration=fix' && false))"
Eslint migration 4 (#13773) A new attempt to migrate!
2025-08-08 14:21:57 +00:00
},
chore: use Nx affected tasks in CI (#5110) Closes #5097 - Uses "nx affected" to detect what projects need to be checked in the current PR (for now, `ci-front` and `ci-server` workflows only). - Caches results of certain tasks (`lint`, `typecheck`, `test`, `storybook:build`) when a PR pipeline runs. The next runs of the same PR's pipeline will then be able to reuse the PR's task cache to execute tasks faster. - Caches Yarn's cache folder to install dependencies faster in CI jobs. - Rewrites the node modules cache/install steps as a custom, reusable Github action. - Distributes `ci-front` jobs with a "matrix" strategy. - Sets common tasks config at the root `nx.json`. For instance, to activate the `typecheck` task in a project, add `typecheck: {}` to its `project.json` and it'll use the default config set in `nx.json` for the `typecheck` task. Options can be overridden in each individual `project.json` if needed. - Adds "scope" tags to some projects: `scope:frontend`, `scope:backend`, `scope:shared`. An eslint rule ensures that `scope:frontend` only depends on `scope:frontent` or `scope:shared` projects, same for `scope:backend`. These tags are used by `nx affected` to filter projects by scope and generates different task cache keys according to the requested scope. - Enables checks for twenty-emails in the `ci-server` workflow.
2024-04-30 14:28:25 +00:00
"configurations": {
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
2026-03-06 00:03:50 +00:00
"ci": {},
Refactor usePersistField (#13775) This PR introduces refactors and tradeoffs in the API around the events of field input. # Refactored usePersistField The hook `usePersistField` has been refactored to be used anywhere in the app, not just inside a FieldContext. This was meant to solve a bug at the beginning but now it is just used once in `RecordDetailRelationSection` outside of the context, still this is better to have this hook like that for future use cases. We also introduce `usePersistFieldFromFieldInputContext`, for an easier API inside a FieldContext. # Introduced a new `FieldInputEventContext` To remove the drill-down of events, we introduce `FieldInputEventContext`, this allows to set only once the handlers / events. In practice it allows to have an easier time maintaining the events for the many different field inputs, because it matches the pattern we already use of taking everything from a context (`FieldContext`). # Removed drill-down from FieldInput The heavy drill-down in FieldInput has been completely removed, since everything can be derived from `FieldContext` and `FieldInputEventContext`. Also there was some readonly and other specific props, but they were all drilled down from FieldContext, so it was easier to just use FieldContext where needed. # Refactored events of `MultiItemFieldInputProps` The component `MultiItemFieldInputProps` has a contrived API, here we just remove the complex part that was persisting from inside. We now only give a classic API with `onChange` and `onEscape` the rest is left to higher levels, where it should be, because this generic component shouldn't be aware of persisting things. # Extracted the parsing logic of persisted values For each input field component, we now have a clear util that was before bound to the persist call, # Tradeoff with persist times The tradeoff before was that persistField was called anywhere, before exiting the component sometimes, now it is only called by the higher levels like table or show page, which handles this abstraction. This could be challenged, however I think that having a lot of different events, and not just `handleSubmit` and `handleCancel`, convey enough meaning for the higher levels to decide what to do in each case. A `skipPersist` argument was added in events in the rare edge cases where we want to voluntarily skip persisting even with a submit or escape, but that could be challenged because we could also say that we should use cancel for that and stick to that convention. # Handling of the bug in `ActivityRichTextEditor` Initially this refactor was prioritized for solving this bug, which was very annoying for the users. But while fixing it with the new persistField hook I just understood that the problem is not just for record title cells but for anything that is open when we click on a rich text editor. The issue is described here : https://github.com/twentyhq/core-team-issues/issues/1317 So right now I just let it as is. # Stories The stories were checking that a request was sent in some cases where persist was called before a component exiting, now that persist is only called by higher-levels I just removed those tests from the stories, because that should be the responsibility of higher levels. Also a helper `getFieldInputEventContextProviderWithJestMocks` was created that exposes a context and jest mock functions for testing this new API in stories. # Miscellaneous Deactivated tui with nx by default, because it can be annoying.
2025-08-12 08:42:13 +00:00
"fix": {
Optimize merge queue to only run E2E and integrate prettier into lint (#18459) ## 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
2026-03-06 12:20:57 +00:00
"command": "npx oxlint --fix -c .oxlintrc.json . && prettier . --write --cache --cache-location ../../.cache/prettier/{projectRoot} --cache-strategy metadata"
Refactor usePersistField (#13775) This PR introduces refactors and tradeoffs in the API around the events of field input. # Refactored usePersistField The hook `usePersistField` has been refactored to be used anywhere in the app, not just inside a FieldContext. This was meant to solve a bug at the beginning but now it is just used once in `RecordDetailRelationSection` outside of the context, still this is better to have this hook like that for future use cases. We also introduce `usePersistFieldFromFieldInputContext`, for an easier API inside a FieldContext. # Introduced a new `FieldInputEventContext` To remove the drill-down of events, we introduce `FieldInputEventContext`, this allows to set only once the handlers / events. In practice it allows to have an easier time maintaining the events for the many different field inputs, because it matches the pattern we already use of taking everything from a context (`FieldContext`). # Removed drill-down from FieldInput The heavy drill-down in FieldInput has been completely removed, since everything can be derived from `FieldContext` and `FieldInputEventContext`. Also there was some readonly and other specific props, but they were all drilled down from FieldContext, so it was easier to just use FieldContext where needed. # Refactored events of `MultiItemFieldInputProps` The component `MultiItemFieldInputProps` has a contrived API, here we just remove the complex part that was persisting from inside. We now only give a classic API with `onChange` and `onEscape` the rest is left to higher levels, where it should be, because this generic component shouldn't be aware of persisting things. # Extracted the parsing logic of persisted values For each input field component, we now have a clear util that was before bound to the persist call, # Tradeoff with persist times The tradeoff before was that persistField was called anywhere, before exiting the component sometimes, now it is only called by the higher levels like table or show page, which handles this abstraction. This could be challenged, however I think that having a lot of different events, and not just `handleSubmit` and `handleCancel`, convey enough meaning for the higher levels to decide what to do in each case. A `skipPersist` argument was added in events in the rare edge cases where we want to voluntarily skip persisting even with a submit or escape, but that could be challenged because we could also say that we should use cancel for that and stick to that convention. # Handling of the bug in `ActivityRichTextEditor` Initially this refactor was prioritized for solving this bug, which was very annoying for the users. But while fixing it with the new persistField hook I just understood that the problem is not just for record title cells but for anything that is open when we click on a rich text editor. The issue is described here : https://github.com/twentyhq/core-team-issues/issues/1317 So right now I just let it as is. # Stories The stories were checking that a request was sent in some cases where persist was called before a component exiting, now that persist is only called by higher-levels I just removed those tests from the stories, because that should be the responsibility of higher levels. Also a helper `getFieldInputEventContextProviderWithJestMocks` was created that exposes a context and jest mock functions for testing this new API in stories. # Miscellaneous Deactivated tui with nx by default, because it can be annoying.
2025-08-12 08:42:13 +00:00
}
Add Twenty Shared & Fix profile image rendering (#8841) PR Summary: 1. Added `Twenty Shared` Package to centralize utilitiies as mentioned in #8942 2. Optimization of `getImageAbsoluteURI.ts` to handle edge cases ![image](https://github.com/user-attachments/assets/c72a3061-6eba-46b8-85ac-869f06bf23c0) --------- Co-authored-by: Antoine Moreaux <moreaux.antoine@gmail.com> Co-authored-by: Charles Bochet <charles@twenty.com>
2024-12-17 08:24:21 +00:00
},
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
2026-03-06 00:03:50 +00:00
"dependsOn": ["^build", "twenty-oxlint-rules:build"]
fix: centralize lint:changed configuration in nx.json (#16877) ## Summary The `lint:changed` command was not using the correct ESLint config for `twenty-server`, causing it to use the root `eslint.config.mjs` instead of the package-specific one. This PR fixes the issue and renames the command to `lint:diff-with-main` for clarity. ## Problem - `twenty-front` correctly specified `--config packages/twenty-front/eslint.config.mjs` - `twenty-server` just called `npx eslint` without specifying a config - This meant `twenty-server` was missing important rules like: - `@typescript-eslint/no-explicit-any: 'error'` - `@stylistic/*` rules (linebreak-style, padding, etc.) - `import/order` with NestJS patterns - Custom workspace rules (`@nx/workspace-inject-workspace-repository`, etc.) ## Solution 1. **Renamed** `lint:changed` to `lint:diff-with-main` to be explicit about what the command does 2. **Centralized** the configuration in `nx.json` targetDefaults: - Uses `{projectRoot}` interpolation for paths (resolved by Nx at runtime) - Each package automatically uses its own ESLint config - Packages can override specific options (e.g., file extension pattern) 3. **Simplified** `project.json` files by inheriting from defaults ## Usage ```bash # Lint only files changed vs main branch npx nx lint:diff-with-main twenty-front npx nx lint:diff-with-main twenty-server # Auto-fix files changed vs main npx nx lint:diff-with-main twenty-front --configuration=fix ``` ## Changes - **nx.json**: Added `lint:diff-with-main` target default with configurable pattern - **twenty-front/project.json**: Simplified to inherit from defaults - **twenty-server/project.json**: Overrides pattern to include `.json` files - **CLAUDE.md** and **.cursor/rules**: Updated documentation
2025-12-31 12:47:20 +00:00
},
"lint:diff-with-main": {
"executor": "nx:run-commands",
"cache": false,
"options": {
Optimize merge queue to only run E2E and integrate prettier into lint (#18459) ## 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
2026-03-06 12:20:57 +00:00
"command": "FILES=$(git diff --name-only --diff-filter=d main -- {projectRoot}/ | grep -E '{args.pattern}'); [ -z \"$FILES\" ] && echo 'No changed files.' || (npx oxlint -c {projectRoot}/.oxlintrc.json $FILES && (prettier --check $FILES || (echo 'ERROR: Prettier formatting check failed! Fix with: npx nx lint:diff-with-main --configuration=fix' && false)))",
fix: centralize lint:changed configuration in nx.json (#16877) ## Summary The `lint:changed` command was not using the correct ESLint config for `twenty-server`, causing it to use the root `eslint.config.mjs` instead of the package-specific one. This PR fixes the issue and renames the command to `lint:diff-with-main` for clarity. ## Problem - `twenty-front` correctly specified `--config packages/twenty-front/eslint.config.mjs` - `twenty-server` just called `npx eslint` without specifying a config - This meant `twenty-server` was missing important rules like: - `@typescript-eslint/no-explicit-any: 'error'` - `@stylistic/*` rules (linebreak-style, padding, etc.) - `import/order` with NestJS patterns - Custom workspace rules (`@nx/workspace-inject-workspace-repository`, etc.) ## Solution 1. **Renamed** `lint:changed` to `lint:diff-with-main` to be explicit about what the command does 2. **Centralized** the configuration in `nx.json` targetDefaults: - Uses `{projectRoot}` interpolation for paths (resolved by Nx at runtime) - Each package automatically uses its own ESLint config - Packages can override specific options (e.g., file extension pattern) 3. **Simplified** `project.json` files by inheriting from defaults ## Usage ```bash # Lint only files changed vs main branch npx nx lint:diff-with-main twenty-front npx nx lint:diff-with-main twenty-server # Auto-fix files changed vs main npx nx lint:diff-with-main twenty-front --configuration=fix ``` ## Changes - **nx.json**: Added `lint:diff-with-main` target default with configurable pattern - **twenty-front/project.json**: Simplified to inherit from defaults - **twenty-server/project.json**: Overrides pattern to include `.json` files - **CLAUDE.md** and **.cursor/rules**: Updated documentation
2025-12-31 12:47:20 +00:00
"pattern": "\\.(ts|tsx|js|jsx)$"
},
"configurations": {
"fix": {
Optimize merge queue to only run E2E and integrate prettier into lint (#18459) ## 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
2026-03-06 12:20:57 +00:00
"command": "FILES=$(git diff --name-only --diff-filter=d main -- {projectRoot}/ | grep -E '{args.pattern}'); [ -z \"$FILES\" ] && echo 'No changed files.' || (npx oxlint --fix -c {projectRoot}/.oxlintrc.json $FILES && prettier --write $FILES)"
fix: centralize lint:changed configuration in nx.json (#16877) ## Summary The `lint:changed` command was not using the correct ESLint config for `twenty-server`, causing it to use the root `eslint.config.mjs` instead of the package-specific one. This PR fixes the issue and renames the command to `lint:diff-with-main` for clarity. ## Problem - `twenty-front` correctly specified `--config packages/twenty-front/eslint.config.mjs` - `twenty-server` just called `npx eslint` without specifying a config - This meant `twenty-server` was missing important rules like: - `@typescript-eslint/no-explicit-any: 'error'` - `@stylistic/*` rules (linebreak-style, padding, etc.) - `import/order` with NestJS patterns - Custom workspace rules (`@nx/workspace-inject-workspace-repository`, etc.) ## Solution 1. **Renamed** `lint:changed` to `lint:diff-with-main` to be explicit about what the command does 2. **Centralized** the configuration in `nx.json` targetDefaults: - Uses `{projectRoot}` interpolation for paths (resolved by Nx at runtime) - Each package automatically uses its own ESLint config - Packages can override specific options (e.g., file extension pattern) 3. **Simplified** `project.json` files by inheriting from defaults ## Usage ```bash # Lint only files changed vs main branch npx nx lint:diff-with-main twenty-front npx nx lint:diff-with-main twenty-server # Auto-fix files changed vs main npx nx lint:diff-with-main twenty-front --configuration=fix ``` ## Changes - **nx.json**: Added `lint:diff-with-main` target default with configurable pattern - **twenty-front/project.json**: Simplified to inherit from defaults - **twenty-server/project.json**: Overrides pattern to include `.json` files - **CLAUDE.md** and **.cursor/rules**: Updated documentation
2025-12-31 12:47:20 +00:00
}
}
chore: use Nx affected tasks in CI (#5110) Closes #5097 - Uses "nx affected" to detect what projects need to be checked in the current PR (for now, `ci-front` and `ci-server` workflows only). - Caches results of certain tasks (`lint`, `typecheck`, `test`, `storybook:build`) when a PR pipeline runs. The next runs of the same PR's pipeline will then be able to reuse the PR's task cache to execute tasks faster. - Caches Yarn's cache folder to install dependencies faster in CI jobs. - Rewrites the node modules cache/install steps as a custom, reusable Github action. - Distributes `ci-front` jobs with a "matrix" strategy. - Sets common tasks config at the root `nx.json`. For instance, to activate the `typecheck` task in a project, add `typecheck: {}` to its `project.json` and it'll use the default config set in `nx.json` for the `typecheck` task. Options can be overridden in each individual `project.json` if needed. - Adds "scope" tags to some projects: `scope:frontend`, `scope:backend`, `scope:shared`. An eslint rule ensures that `scope:frontend` only depends on `scope:frontent` or `scope:shared` projects, same for `scope:backend`. These tags are used by `nx affected` to filter projects by scope and generates different task cache keys according to the requested scope. - Enables checks for twenty-emails in the `ci-server` workflow.
2024-04-30 14:28:25 +00:00
},
"fmt": {
"executor": "nx:run-commands",
"cache": true,
"options": {
"cwd": "{projectRoot}",
"command": "prettier {args.files} --check --cache {args.cache} --cache-location {args.cacheLocation} --write {args.write} --cache-strategy {args.cacheStrategy}",
"cache": true,
"cacheLocation": "../../.cache/prettier/{projectRoot}",
"cacheStrategy": "metadata",
"write": false
},
"configurations": {
Refactor usePersistField (#13775) This PR introduces refactors and tradeoffs in the API around the events of field input. # Refactored usePersistField The hook `usePersistField` has been refactored to be used anywhere in the app, not just inside a FieldContext. This was meant to solve a bug at the beginning but now it is just used once in `RecordDetailRelationSection` outside of the context, still this is better to have this hook like that for future use cases. We also introduce `usePersistFieldFromFieldInputContext`, for an easier API inside a FieldContext. # Introduced a new `FieldInputEventContext` To remove the drill-down of events, we introduce `FieldInputEventContext`, this allows to set only once the handlers / events. In practice it allows to have an easier time maintaining the events for the many different field inputs, because it matches the pattern we already use of taking everything from a context (`FieldContext`). # Removed drill-down from FieldInput The heavy drill-down in FieldInput has been completely removed, since everything can be derived from `FieldContext` and `FieldInputEventContext`. Also there was some readonly and other specific props, but they were all drilled down from FieldContext, so it was easier to just use FieldContext where needed. # Refactored events of `MultiItemFieldInputProps` The component `MultiItemFieldInputProps` has a contrived API, here we just remove the complex part that was persisting from inside. We now only give a classic API with `onChange` and `onEscape` the rest is left to higher levels, where it should be, because this generic component shouldn't be aware of persisting things. # Extracted the parsing logic of persisted values For each input field component, we now have a clear util that was before bound to the persist call, # Tradeoff with persist times The tradeoff before was that persistField was called anywhere, before exiting the component sometimes, now it is only called by the higher levels like table or show page, which handles this abstraction. This could be challenged, however I think that having a lot of different events, and not just `handleSubmit` and `handleCancel`, convey enough meaning for the higher levels to decide what to do in each case. A `skipPersist` argument was added in events in the rare edge cases where we want to voluntarily skip persisting even with a submit or escape, but that could be challenged because we could also say that we should use cancel for that and stick to that convention. # Handling of the bug in `ActivityRichTextEditor` Initially this refactor was prioritized for solving this bug, which was very annoying for the users. But while fixing it with the new persistField hook I just understood that the problem is not just for record title cells but for anything that is open when we click on a rich text editor. The issue is described here : https://github.com/twentyhq/core-team-issues/issues/1317 So right now I just let it as is. # Stories The stories were checking that a request was sent in some cases where persist was called before a component exiting, now that persist is only called by higher-levels I just removed those tests from the stories, because that should be the responsibility of higher levels. Also a helper `getFieldInputEventContextProviderWithJestMocks` was created that exposes a context and jest mock functions for testing this new API in stories. # Miscellaneous Deactivated tui with nx by default, because it can be annoying.
2025-08-12 08:42:13 +00:00
"ci": {
"cacheStrategy": "content"
},
"fix": {
"write": true
}
Add Twenty Shared & Fix profile image rendering (#8841) PR Summary: 1. Added `Twenty Shared` Package to centralize utilitiies as mentioned in #8942 2. Optimization of `getImageAbsoluteURI.ts` to handle edge cases ![image](https://github.com/user-attachments/assets/c72a3061-6eba-46b8-85ac-869f06bf23c0) --------- Co-authored-by: Antoine Moreaux <moreaux.antoine@gmail.com> Co-authored-by: Charles Bochet <charles@twenty.com>
2024-12-17 08:24:21 +00:00
},
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.)
2026-01-17 06:37:17 +00:00
"dependsOn": ["^build"]
chore: use Nx affected tasks in CI (#5110) Closes #5097 - Uses "nx affected" to detect what projects need to be checked in the current PR (for now, `ci-front` and `ci-server` workflows only). - Caches results of certain tasks (`lint`, `typecheck`, `test`, `storybook:build`) when a PR pipeline runs. The next runs of the same PR's pipeline will then be able to reuse the PR's task cache to execute tasks faster. - Caches Yarn's cache folder to install dependencies faster in CI jobs. - Rewrites the node modules cache/install steps as a custom, reusable Github action. - Distributes `ci-front` jobs with a "matrix" strategy. - Sets common tasks config at the root `nx.json`. For instance, to activate the `typecheck` task in a project, add `typecheck: {}` to its `project.json` and it'll use the default config set in `nx.json` for the `typecheck` task. Options can be overridden in each individual `project.json` if needed. - Adds "scope" tags to some projects: `scope:frontend`, `scope:backend`, `scope:shared`. An eslint rule ensures that `scope:frontend` only depends on `scope:frontent` or `scope:shared` projects, same for `scope:backend`. These tags are used by `nx affected` to filter projects by scope and generates different task cache keys according to the requested scope. - Enables checks for twenty-emails in the `ci-server` workflow.
2024-04-30 14:28:25 +00:00
},
"typecheck": {
"executor": "nx:run-commands",
"cache": true,
"options": {
"cwd": "{projectRoot}",
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
2026-01-19 11:46:34 +00:00
"command": "tsgo -p tsconfig.json"
chore: use Nx affected tasks in CI (#5110) Closes #5097 - Uses "nx affected" to detect what projects need to be checked in the current PR (for now, `ci-front` and `ci-server` workflows only). - Caches results of certain tasks (`lint`, `typecheck`, `test`, `storybook:build`) when a PR pipeline runs. The next runs of the same PR's pipeline will then be able to reuse the PR's task cache to execute tasks faster. - Caches Yarn's cache folder to install dependencies faster in CI jobs. - Rewrites the node modules cache/install steps as a custom, reusable Github action. - Distributes `ci-front` jobs with a "matrix" strategy. - Sets common tasks config at the root `nx.json`. For instance, to activate the `typecheck` task in a project, add `typecheck: {}` to its `project.json` and it'll use the default config set in `nx.json` for the `typecheck` task. Options can be overridden in each individual `project.json` if needed. - Adds "scope" tags to some projects: `scope:frontend`, `scope:backend`, `scope:shared`. An eslint rule ensures that `scope:frontend` only depends on `scope:frontent` or `scope:shared` projects, same for `scope:backend`. These tags are used by `nx affected` to filter projects by scope and generates different task cache keys according to the requested scope. - Enables checks for twenty-emails in the `ci-server` workflow.
2024-04-30 14:28:25 +00:00
},
Refactor usePersistField (#13775) This PR introduces refactors and tradeoffs in the API around the events of field input. # Refactored usePersistField The hook `usePersistField` has been refactored to be used anywhere in the app, not just inside a FieldContext. This was meant to solve a bug at the beginning but now it is just used once in `RecordDetailRelationSection` outside of the context, still this is better to have this hook like that for future use cases. We also introduce `usePersistFieldFromFieldInputContext`, for an easier API inside a FieldContext. # Introduced a new `FieldInputEventContext` To remove the drill-down of events, we introduce `FieldInputEventContext`, this allows to set only once the handlers / events. In practice it allows to have an easier time maintaining the events for the many different field inputs, because it matches the pattern we already use of taking everything from a context (`FieldContext`). # Removed drill-down from FieldInput The heavy drill-down in FieldInput has been completely removed, since everything can be derived from `FieldContext` and `FieldInputEventContext`. Also there was some readonly and other specific props, but they were all drilled down from FieldContext, so it was easier to just use FieldContext where needed. # Refactored events of `MultiItemFieldInputProps` The component `MultiItemFieldInputProps` has a contrived API, here we just remove the complex part that was persisting from inside. We now only give a classic API with `onChange` and `onEscape` the rest is left to higher levels, where it should be, because this generic component shouldn't be aware of persisting things. # Extracted the parsing logic of persisted values For each input field component, we now have a clear util that was before bound to the persist call, # Tradeoff with persist times The tradeoff before was that persistField was called anywhere, before exiting the component sometimes, now it is only called by the higher levels like table or show page, which handles this abstraction. This could be challenged, however I think that having a lot of different events, and not just `handleSubmit` and `handleCancel`, convey enough meaning for the higher levels to decide what to do in each case. A `skipPersist` argument was added in events in the rare edge cases where we want to voluntarily skip persisting even with a submit or escape, but that could be challenged because we could also say that we should use cancel for that and stick to that convention. # Handling of the bug in `ActivityRichTextEditor` Initially this refactor was prioritized for solving this bug, which was very annoying for the users. But while fixing it with the new persistField hook I just understood that the problem is not just for record title cells but for anything that is open when we click on a rich text editor. The issue is described here : https://github.com/twentyhq/core-team-issues/issues/1317 So right now I just let it as is. # Stories The stories were checking that a request was sent in some cases where persist was called before a component exiting, now that persist is only called by higher-levels I just removed those tests from the stories, because that should be the responsibility of higher levels. Also a helper `getFieldInputEventContextProviderWithJestMocks` was created that exposes a context and jest mock functions for testing this new API in stories. # Miscellaneous Deactivated tui with nx by default, because it can be annoying.
2025-08-12 08:42:13 +00:00
"configurations": {
"watch": {
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
2026-01-19 11:46:34 +00:00
"command": "tsgo -p tsconfig.json --watch"
Refactor usePersistField (#13775) This PR introduces refactors and tradeoffs in the API around the events of field input. # Refactored usePersistField The hook `usePersistField` has been refactored to be used anywhere in the app, not just inside a FieldContext. This was meant to solve a bug at the beginning but now it is just used once in `RecordDetailRelationSection` outside of the context, still this is better to have this hook like that for future use cases. We also introduce `usePersistFieldFromFieldInputContext`, for an easier API inside a FieldContext. # Introduced a new `FieldInputEventContext` To remove the drill-down of events, we introduce `FieldInputEventContext`, this allows to set only once the handlers / events. In practice it allows to have an easier time maintaining the events for the many different field inputs, because it matches the pattern we already use of taking everything from a context (`FieldContext`). # Removed drill-down from FieldInput The heavy drill-down in FieldInput has been completely removed, since everything can be derived from `FieldContext` and `FieldInputEventContext`. Also there was some readonly and other specific props, but they were all drilled down from FieldContext, so it was easier to just use FieldContext where needed. # Refactored events of `MultiItemFieldInputProps` The component `MultiItemFieldInputProps` has a contrived API, here we just remove the complex part that was persisting from inside. We now only give a classic API with `onChange` and `onEscape` the rest is left to higher levels, where it should be, because this generic component shouldn't be aware of persisting things. # Extracted the parsing logic of persisted values For each input field component, we now have a clear util that was before bound to the persist call, # Tradeoff with persist times The tradeoff before was that persistField was called anywhere, before exiting the component sometimes, now it is only called by the higher levels like table or show page, which handles this abstraction. This could be challenged, however I think that having a lot of different events, and not just `handleSubmit` and `handleCancel`, convey enough meaning for the higher levels to decide what to do in each case. A `skipPersist` argument was added in events in the rare edge cases where we want to voluntarily skip persisting even with a submit or escape, but that could be challenged because we could also say that we should use cancel for that and stick to that convention. # Handling of the bug in `ActivityRichTextEditor` Initially this refactor was prioritized for solving this bug, which was very annoying for the users. But while fixing it with the new persistField hook I just understood that the problem is not just for record title cells but for anything that is open when we click on a rich text editor. The issue is described here : https://github.com/twentyhq/core-team-issues/issues/1317 So right now I just let it as is. # Stories The stories were checking that a request was sent in some cases where persist was called before a component exiting, now that persist is only called by higher-levels I just removed those tests from the stories, because that should be the responsibility of higher levels. Also a helper `getFieldInputEventContextProviderWithJestMocks` was created that exposes a context and jest mock functions for testing this new API in stories. # Miscellaneous Deactivated tui with nx by default, because it can be annoying.
2025-08-12 08:42:13 +00:00
}
},
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.)
2026-01-17 06:37:17 +00:00
"dependsOn": ["^build"]
Migrate to a monorepo structure (#2909)
2023-12-10 17:10:54 +00:00
},
"test": {
chore: use Nx affected tasks in CI (#5110) Closes #5097 - Uses "nx affected" to detect what projects need to be checked in the current PR (for now, `ci-front` and `ci-server` workflows only). - Caches results of certain tasks (`lint`, `typecheck`, `test`, `storybook:build`) when a PR pipeline runs. The next runs of the same PR's pipeline will then be able to reuse the PR's task cache to execute tasks faster. - Caches Yarn's cache folder to install dependencies faster in CI jobs. - Rewrites the node modules cache/install steps as a custom, reusable Github action. - Distributes `ci-front` jobs with a "matrix" strategy. - Sets common tasks config at the root `nx.json`. For instance, to activate the `typecheck` task in a project, add `typecheck: {}` to its `project.json` and it'll use the default config set in `nx.json` for the `typecheck` task. Options can be overridden in each individual `project.json` if needed. - Adds "scope" tags to some projects: `scope:frontend`, `scope:backend`, `scope:shared`. An eslint rule ensures that `scope:frontend` only depends on `scope:frontent` or `scope:shared` projects, same for `scope:backend`. These tags are used by `nx affected` to filter projects by scope and generates different task cache keys according to the requested scope. - Enables checks for twenty-emails in the `ci-server` workflow.
2024-04-30 14:28:25 +00:00
"executor": "@nx/jest:jest",
chore: set up twenty-emails config so build isn't needed in development (#3619) * chore: set up twenty-emails config so build isn't needed in development * fix: fix script dependency * chore: use @vitejs/plugin-react-swc * Remove useless dependancy * Fix typing * chore: use baseUrl in twenty-emails * chore: fix docker server prod build * refactor: optimize Docker file and tsconfig * fix: fix WORKDIR in docker --------- Co-authored-by: martmull <martmull@hotmail.fr>
2024-01-29 09:17:12 +00:00
"cache": true,
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.)
2026-01-17 06:37:17 +00:00
"dependsOn": ["^build"],
fix: fix storybook coverage task (#5256) - Fixes storybook coverage command: the coverage directory path was incorrect, but instead of failing `storybook:test --configuration=ci`, it was hanging indefinitely. - Switches back to `concurrently` to launch `storybook:static` and `storybook:test` in parallel, which allows to use options to explicitly kill `storybook:static` when `storybook:test` fails. - Moves `storybook:test --configuration=ci` to its own command `storybook:static:test`: used in the CI, and can be used locally to run storybook tests without having to launch `storybook:dev` first. - Creates command `storybook:coverage` and enables cache for this command. - Fixes Jest tests that were failing. - Improves caching conditions for some tasks (for instance, no need to invalidate Jest test cache if only Storybook story files were modified).
2024-05-03 12:59:09 +00:00
"inputs": [
"^default",
"excludeStories",
"{workspaceRoot}/jest.preset.js"
],
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.)
2026-01-17 06:37:17 +00:00
"outputs": ["{projectRoot}/coverage"],
chore: use Nx affected tasks in CI (#5110) Closes #5097 - Uses "nx affected" to detect what projects need to be checked in the current PR (for now, `ci-front` and `ci-server` workflows only). - Caches results of certain tasks (`lint`, `typecheck`, `test`, `storybook:build`) when a PR pipeline runs. The next runs of the same PR's pipeline will then be able to reuse the PR's task cache to execute tasks faster. - Caches Yarn's cache folder to install dependencies faster in CI jobs. - Rewrites the node modules cache/install steps as a custom, reusable Github action. - Distributes `ci-front` jobs with a "matrix" strategy. - Sets common tasks config at the root `nx.json`. For instance, to activate the `typecheck` task in a project, add `typecheck: {}` to its `project.json` and it'll use the default config set in `nx.json` for the `typecheck` task. Options can be overridden in each individual `project.json` if needed. - Adds "scope" tags to some projects: `scope:frontend`, `scope:backend`, `scope:shared`. An eslint rule ensures that `scope:frontend` only depends on `scope:frontent` or `scope:shared` projects, same for `scope:backend`. These tags are used by `nx affected` to filter projects by scope and generates different task cache keys according to the requested scope. - Enables checks for twenty-emails in the `ci-server` workflow.
2024-04-30 14:28:25 +00:00
"options": {
Refactor read only object and fields (#13936) Co-authored-by: Charles Bochet <charles@twenty.com>
2025-08-19 16:10:35 +00:00
"jestConfig": "{projectRoot}/jest.config.mjs",
feat: show auto-generated conversation title for AI chat. (#17922) ## Summary Replaces the static "Ask AI" header in the command menu with the conversation’s auto-generated title once it’s set after the first message. ## Changes - **Backend:** Title is generated after the first user message (existing behavior). - **Frontend:** After the first stream completes, we fetch the thread title and sync it to: - `currentAIChatThreadTitleState` (persists across command menu close/reopen) - Command menu page info and navigation stack (so the title survives back navigation) - **Entry points:** Opening Ask AI from the left nav or command center uses the same title resolution (explicit `pageTitle` → current thread title → "Ask AI" fallback). - **Race fix:** Title sync only runs when the thread that finished streaming is still the active thread, so switching threads mid-stream doesn’t overwrite the current thread’s title. --------- Co-authored-by: Félix Malfait <felix@twenty.com> Co-authored-by: Cursor <cursoragent@cursor.com>
2026-02-17 12:46:35 +00:00
"silent": true,
chore: use Nx affected tasks in CI (#5110) Closes #5097 - Uses "nx affected" to detect what projects need to be checked in the current PR (for now, `ci-front` and `ci-server` workflows only). - Caches results of certain tasks (`lint`, `typecheck`, `test`, `storybook:build`) when a PR pipeline runs. The next runs of the same PR's pipeline will then be able to reuse the PR's task cache to execute tasks faster. - Caches Yarn's cache folder to install dependencies faster in CI jobs. - Rewrites the node modules cache/install steps as a custom, reusable Github action. - Distributes `ci-front` jobs with a "matrix" strategy. - Sets common tasks config at the root `nx.json`. For instance, to activate the `typecheck` task in a project, add `typecheck: {}` to its `project.json` and it'll use the default config set in `nx.json` for the `typecheck` task. Options can be overridden in each individual `project.json` if needed. - Adds "scope" tags to some projects: `scope:frontend`, `scope:backend`, `scope:shared`. An eslint rule ensures that `scope:frontend` only depends on `scope:frontent` or `scope:shared` projects, same for `scope:backend`. These tags are used by `nx affected` to filter projects by scope and generates different task cache keys according to the requested scope. - Enables checks for twenty-emails in the `ci-server` workflow.
2024-04-30 14:28:25 +00:00
"coverage": true,
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.)
2026-01-17 06:37:17 +00:00
"coverageReporters": ["text-summary"],
chore: use Nx affected tasks in CI (#5110) Closes #5097 - Uses "nx affected" to detect what projects need to be checked in the current PR (for now, `ci-front` and `ci-server` workflows only). - Caches results of certain tasks (`lint`, `typecheck`, `test`, `storybook:build`) when a PR pipeline runs. The next runs of the same PR's pipeline will then be able to reuse the PR's task cache to execute tasks faster. - Caches Yarn's cache folder to install dependencies faster in CI jobs. - Rewrites the node modules cache/install steps as a custom, reusable Github action. - Distributes `ci-front` jobs with a "matrix" strategy. - Sets common tasks config at the root `nx.json`. For instance, to activate the `typecheck` task in a project, add `typecheck: {}` to its `project.json` and it'll use the default config set in `nx.json` for the `typecheck` task. Options can be overridden in each individual `project.json` if needed. - Adds "scope" tags to some projects: `scope:frontend`, `scope:backend`, `scope:shared`. An eslint rule ensures that `scope:frontend` only depends on `scope:frontent` or `scope:shared` projects, same for `scope:backend`. These tags are used by `nx affected` to filter projects by scope and generates different task cache keys according to the requested scope. - Enables checks for twenty-emails in the `ci-server` workflow.
2024-04-30 14:28:25 +00:00
"cacheDirectory": "../../.cache/jest/{projectRoot}"
},
"configurations": {
Refactor usePersistField (#13775) This PR introduces refactors and tradeoffs in the API around the events of field input. # Refactored usePersistField The hook `usePersistField` has been refactored to be used anywhere in the app, not just inside a FieldContext. This was meant to solve a bug at the beginning but now it is just used once in `RecordDetailRelationSection` outside of the context, still this is better to have this hook like that for future use cases. We also introduce `usePersistFieldFromFieldInputContext`, for an easier API inside a FieldContext. # Introduced a new `FieldInputEventContext` To remove the drill-down of events, we introduce `FieldInputEventContext`, this allows to set only once the handlers / events. In practice it allows to have an easier time maintaining the events for the many different field inputs, because it matches the pattern we already use of taking everything from a context (`FieldContext`). # Removed drill-down from FieldInput The heavy drill-down in FieldInput has been completely removed, since everything can be derived from `FieldContext` and `FieldInputEventContext`. Also there was some readonly and other specific props, but they were all drilled down from FieldContext, so it was easier to just use FieldContext where needed. # Refactored events of `MultiItemFieldInputProps` The component `MultiItemFieldInputProps` has a contrived API, here we just remove the complex part that was persisting from inside. We now only give a classic API with `onChange` and `onEscape` the rest is left to higher levels, where it should be, because this generic component shouldn't be aware of persisting things. # Extracted the parsing logic of persisted values For each input field component, we now have a clear util that was before bound to the persist call, # Tradeoff with persist times The tradeoff before was that persistField was called anywhere, before exiting the component sometimes, now it is only called by the higher levels like table or show page, which handles this abstraction. This could be challenged, however I think that having a lot of different events, and not just `handleSubmit` and `handleCancel`, convey enough meaning for the higher levels to decide what to do in each case. A `skipPersist` argument was added in events in the rare edge cases where we want to voluntarily skip persisting even with a submit or escape, but that could be challenged because we could also say that we should use cancel for that and stick to that convention. # Handling of the bug in `ActivityRichTextEditor` Initially this refactor was prioritized for solving this bug, which was very annoying for the users. But while fixing it with the new persistField hook I just understood that the problem is not just for record title cells but for anything that is open when we click on a rich text editor. The issue is described here : https://github.com/twentyhq/core-team-issues/issues/1317 So right now I just let it as is. # Stories The stories were checking that a request was sent in some cases where persist was called before a component exiting, now that persist is only called by higher-levels I just removed those tests from the stories, because that should be the responsibility of higher levels. Also a helper `getFieldInputEventContextProviderWithJestMocks` was created that exposes a context and jest mock functions for testing this new API in stories. # Miscellaneous Deactivated tui with nx by default, because it can be annoying.
2025-08-12 08:42:13 +00:00
"ci": {
"ci": true,
Fix twenty-sdk typecheck race condition (#18246) ## Fix SDK first-run build failure when generated API client is missing ### Problem When running `twenty app:dev` for the first time, the build pipeline crashes because: 1. The esbuild front-component watcher tries to resolve `twenty-sdk/generated`, but the generated API client doesn't exist yet — it's only created later in the pipeline after syncing with the server. 2. The typecheck plugin (`tsc --noEmit`) runs as a blocking esbuild `onStart` hook, so even with stub files, type errors on the empty client classes (e.g. `Property 'query' does not exist on type 'CoreApiClient'`) cause the build to fail before the real client can be generated. This creates a chicken-and-egg problem: the watchers need the generated client to build, but the client is generated after the watchers produce their output. ### Solution **1. Stub generated client on startup** Added `ensureGeneratedClientStub` to `ClientService` that writes minimal placeholder files (`CoreApiClient`, `MetadataApiClient`) into `node_modules/twenty-sdk/generated/` if the directory doesn't already exist. This is called in `DevModeOrchestrator.start()` before any watchers are created, so the `twenty-sdk/generated` import always resolves. **2. Skip typecheck on first sync round** Made the esbuild typecheck plugin accept a `shouldSkipTypecheck` callback. The orchestrator starts with `skipTypecheck = true` and passes `() => this.skipTypecheck` through the watcher chain. After the real API client is generated, the flag is flipped to `false`, so subsequent rebuilds enforce full type checking with the real generated types.
2026-02-25 22:47:08 +00:00
"maxWorkers": 1
Refactor usePersistField (#13775) This PR introduces refactors and tradeoffs in the API around the events of field input. # Refactored usePersistField The hook `usePersistField` has been refactored to be used anywhere in the app, not just inside a FieldContext. This was meant to solve a bug at the beginning but now it is just used once in `RecordDetailRelationSection` outside of the context, still this is better to have this hook like that for future use cases. We also introduce `usePersistFieldFromFieldInputContext`, for an easier API inside a FieldContext. # Introduced a new `FieldInputEventContext` To remove the drill-down of events, we introduce `FieldInputEventContext`, this allows to set only once the handlers / events. In practice it allows to have an easier time maintaining the events for the many different field inputs, because it matches the pattern we already use of taking everything from a context (`FieldContext`). # Removed drill-down from FieldInput The heavy drill-down in FieldInput has been completely removed, since everything can be derived from `FieldContext` and `FieldInputEventContext`. Also there was some readonly and other specific props, but they were all drilled down from FieldContext, so it was easier to just use FieldContext where needed. # Refactored events of `MultiItemFieldInputProps` The component `MultiItemFieldInputProps` has a contrived API, here we just remove the complex part that was persisting from inside. We now only give a classic API with `onChange` and `onEscape` the rest is left to higher levels, where it should be, because this generic component shouldn't be aware of persisting things. # Extracted the parsing logic of persisted values For each input field component, we now have a clear util that was before bound to the persist call, # Tradeoff with persist times The tradeoff before was that persistField was called anywhere, before exiting the component sometimes, now it is only called by the higher levels like table or show page, which handles this abstraction. This could be challenged, however I think that having a lot of different events, and not just `handleSubmit` and `handleCancel`, convey enough meaning for the higher levels to decide what to do in each case. A `skipPersist` argument was added in events in the rare edge cases where we want to voluntarily skip persisting even with a submit or escape, but that could be challenged because we could also say that we should use cancel for that and stick to that convention. # Handling of the bug in `ActivityRichTextEditor` Initially this refactor was prioritized for solving this bug, which was very annoying for the users. But while fixing it with the new persistField hook I just understood that the problem is not just for record title cells but for anything that is open when we click on a rich text editor. The issue is described here : https://github.com/twentyhq/core-team-issues/issues/1317 So right now I just let it as is. # Stories The stories were checking that a request was sent in some cases where persist was called before a component exiting, now that persist is only called by higher-levels I just removed those tests from the stories, because that should be the responsibility of higher levels. Also a helper `getFieldInputEventContextProviderWithJestMocks` was created that exposes a context and jest mock functions for testing this new API in stories. # Miscellaneous Deactivated tui with nx by default, because it can be annoying.
2025-08-12 08:42:13 +00:00
},
"coverage": {
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.)
2026-01-17 06:37:17 +00:00
"coverageReporters": ["lcov", "text"]
Refactor usePersistField (#13775) This PR introduces refactors and tradeoffs in the API around the events of field input. # Refactored usePersistField The hook `usePersistField` has been refactored to be used anywhere in the app, not just inside a FieldContext. This was meant to solve a bug at the beginning but now it is just used once in `RecordDetailRelationSection` outside of the context, still this is better to have this hook like that for future use cases. We also introduce `usePersistFieldFromFieldInputContext`, for an easier API inside a FieldContext. # Introduced a new `FieldInputEventContext` To remove the drill-down of events, we introduce `FieldInputEventContext`, this allows to set only once the handlers / events. In practice it allows to have an easier time maintaining the events for the many different field inputs, because it matches the pattern we already use of taking everything from a context (`FieldContext`). # Removed drill-down from FieldInput The heavy drill-down in FieldInput has been completely removed, since everything can be derived from `FieldContext` and `FieldInputEventContext`. Also there was some readonly and other specific props, but they were all drilled down from FieldContext, so it was easier to just use FieldContext where needed. # Refactored events of `MultiItemFieldInputProps` The component `MultiItemFieldInputProps` has a contrived API, here we just remove the complex part that was persisting from inside. We now only give a classic API with `onChange` and `onEscape` the rest is left to higher levels, where it should be, because this generic component shouldn't be aware of persisting things. # Extracted the parsing logic of persisted values For each input field component, we now have a clear util that was before bound to the persist call, # Tradeoff with persist times The tradeoff before was that persistField was called anywhere, before exiting the component sometimes, now it is only called by the higher levels like table or show page, which handles this abstraction. This could be challenged, however I think that having a lot of different events, and not just `handleSubmit` and `handleCancel`, convey enough meaning for the higher levels to decide what to do in each case. A `skipPersist` argument was added in events in the rare edge cases where we want to voluntarily skip persisting even with a submit or escape, but that could be challenged because we could also say that we should use cancel for that and stick to that convention. # Handling of the bug in `ActivityRichTextEditor` Initially this refactor was prioritized for solving this bug, which was very annoying for the users. But while fixing it with the new persistField hook I just understood that the problem is not just for record title cells but for anything that is open when we click on a rich text editor. The issue is described here : https://github.com/twentyhq/core-team-issues/issues/1317 So right now I just let it as is. # Stories The stories were checking that a request was sent in some cases where persist was called before a component exiting, now that persist is only called by higher-levels I just removed those tests from the stories, because that should be the responsibility of higher levels. Also a helper `getFieldInputEventContextProviderWithJestMocks` was created that exposes a context and jest mock functions for testing this new API in stories. # Miscellaneous Deactivated tui with nx by default, because it can be annoying.
2025-08-12 08:42:13 +00:00
},
"watch": {
"watch": true
}
chore: use Nx affected tasks in CI (#5110) Closes #5097 - Uses "nx affected" to detect what projects need to be checked in the current PR (for now, `ci-front` and `ci-server` workflows only). - Caches results of certain tasks (`lint`, `typecheck`, `test`, `storybook:build`) when a PR pipeline runs. The next runs of the same PR's pipeline will then be able to reuse the PR's task cache to execute tasks faster. - Caches Yarn's cache folder to install dependencies faster in CI jobs. - Rewrites the node modules cache/install steps as a custom, reusable Github action. - Distributes `ci-front` jobs with a "matrix" strategy. - Sets common tasks config at the root `nx.json`. For instance, to activate the `typecheck` task in a project, add `typecheck: {}` to its `project.json` and it'll use the default config set in `nx.json` for the `typecheck` task. Options can be overridden in each individual `project.json` if needed. - Adds "scope" tags to some projects: `scope:frontend`, `scope:backend`, `scope:shared`. An eslint rule ensures that `scope:frontend` only depends on `scope:frontent` or `scope:shared` projects, same for `scope:backend`. These tags are used by `nx affected` to filter projects by scope and generates different task cache keys according to the requested scope. - Enables checks for twenty-emails in the `ci-server` workflow.
2024-04-30 14:28:25 +00:00
}
Migrate to a monorepo structure (#2909)
2023-12-10 17:10:54 +00:00
},
Refactor usePersistField (#13775) This PR introduces refactors and tradeoffs in the API around the events of field input. # Refactored usePersistField The hook `usePersistField` has been refactored to be used anywhere in the app, not just inside a FieldContext. This was meant to solve a bug at the beginning but now it is just used once in `RecordDetailRelationSection` outside of the context, still this is better to have this hook like that for future use cases. We also introduce `usePersistFieldFromFieldInputContext`, for an easier API inside a FieldContext. # Introduced a new `FieldInputEventContext` To remove the drill-down of events, we introduce `FieldInputEventContext`, this allows to set only once the handlers / events. In practice it allows to have an easier time maintaining the events for the many different field inputs, because it matches the pattern we already use of taking everything from a context (`FieldContext`). # Removed drill-down from FieldInput The heavy drill-down in FieldInput has been completely removed, since everything can be derived from `FieldContext` and `FieldInputEventContext`. Also there was some readonly and other specific props, but they were all drilled down from FieldContext, so it was easier to just use FieldContext where needed. # Refactored events of `MultiItemFieldInputProps` The component `MultiItemFieldInputProps` has a contrived API, here we just remove the complex part that was persisting from inside. We now only give a classic API with `onChange` and `onEscape` the rest is left to higher levels, where it should be, because this generic component shouldn't be aware of persisting things. # Extracted the parsing logic of persisted values For each input field component, we now have a clear util that was before bound to the persist call, # Tradeoff with persist times The tradeoff before was that persistField was called anywhere, before exiting the component sometimes, now it is only called by the higher levels like table or show page, which handles this abstraction. This could be challenged, however I think that having a lot of different events, and not just `handleSubmit` and `handleCancel`, convey enough meaning for the higher levels to decide what to do in each case. A `skipPersist` argument was added in events in the rare edge cases where we want to voluntarily skip persisting even with a submit or escape, but that could be challenged because we could also say that we should use cancel for that and stick to that convention. # Handling of the bug in `ActivityRichTextEditor` Initially this refactor was prioritized for solving this bug, which was very annoying for the users. But while fixing it with the new persistField hook I just understood that the problem is not just for record title cells but for anything that is open when we click on a rich text editor. The issue is described here : https://github.com/twentyhq/core-team-issues/issues/1317 So right now I just let it as is. # Stories The stories were checking that a request was sent in some cases where persist was called before a component exiting, now that persist is only called by higher-levels I just removed those tests from the stories, because that should be the responsibility of higher levels. Also a helper `getFieldInputEventContextProviderWithJestMocks` was created that exposes a context and jest mock functions for testing this new API in stories. # Miscellaneous Deactivated tui with nx by default, because it can be annoying.
2025-08-12 08:42:13 +00:00
"test:e2e": {
"cache": true,
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.)
2026-01-17 06:37:17 +00:00
"dependsOn": ["^build"]
Refactor usePersistField (#13775) This PR introduces refactors and tradeoffs in the API around the events of field input. # Refactored usePersistField The hook `usePersistField` has been refactored to be used anywhere in the app, not just inside a FieldContext. This was meant to solve a bug at the beginning but now it is just used once in `RecordDetailRelationSection` outside of the context, still this is better to have this hook like that for future use cases. We also introduce `usePersistFieldFromFieldInputContext`, for an easier API inside a FieldContext. # Introduced a new `FieldInputEventContext` To remove the drill-down of events, we introduce `FieldInputEventContext`, this allows to set only once the handlers / events. In practice it allows to have an easier time maintaining the events for the many different field inputs, because it matches the pattern we already use of taking everything from a context (`FieldContext`). # Removed drill-down from FieldInput The heavy drill-down in FieldInput has been completely removed, since everything can be derived from `FieldContext` and `FieldInputEventContext`. Also there was some readonly and other specific props, but they were all drilled down from FieldContext, so it was easier to just use FieldContext where needed. # Refactored events of `MultiItemFieldInputProps` The component `MultiItemFieldInputProps` has a contrived API, here we just remove the complex part that was persisting from inside. We now only give a classic API with `onChange` and `onEscape` the rest is left to higher levels, where it should be, because this generic component shouldn't be aware of persisting things. # Extracted the parsing logic of persisted values For each input field component, we now have a clear util that was before bound to the persist call, # Tradeoff with persist times The tradeoff before was that persistField was called anywhere, before exiting the component sometimes, now it is only called by the higher levels like table or show page, which handles this abstraction. This could be challenged, however I think that having a lot of different events, and not just `handleSubmit` and `handleCancel`, convey enough meaning for the higher levels to decide what to do in each case. A `skipPersist` argument was added in events in the rare edge cases where we want to voluntarily skip persisting even with a submit or escape, but that could be challenged because we could also say that we should use cancel for that and stick to that convention. # Handling of the bug in `ActivityRichTextEditor` Initially this refactor was prioritized for solving this bug, which was very annoying for the users. But while fixing it with the new persistField hook I just understood that the problem is not just for record title cells but for anything that is open when we click on a rich text editor. The issue is described here : https://github.com/twentyhq/core-team-issues/issues/1317 So right now I just let it as is. # Stories The stories were checking that a request was sent in some cases where persist was called before a component exiting, now that persist is only called by higher-levels I just removed those tests from the stories, because that should be the responsibility of higher levels. Also a helper `getFieldInputEventContextProviderWithJestMocks` was created that exposes a context and jest mock functions for testing this new API in stories. # Miscellaneous Deactivated tui with nx by default, because it can be annoying.
2025-08-12 08:42:13 +00:00
},
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
2026-03-11 15:30:28 +00:00
"set-local-version": {
"executor": "nx:run-commands",
"cache": false,
"options": {
"cwd": "{projectRoot}",
fix: replace npm pkg set with node script in set-local-version target (#19344) ## Summary - Replaces `npm pkg set version=X` with a direct `node -e` script in the `set-local-version` Nx target - Fixes `CI Create App E2E minimal` workflow failures on fork PRs where `npm pkg set` fails with `EJSONPARSE: Unexpected end of JSON input while parsing empty string` The `npm` command has unreliable `package.json` resolution in certain CI checkout contexts (shallow clones of fork PR merge refs). Using `node` directly to read/write the JSON file avoids this entirely.
2026-04-05 18:56:37 +00:00
"command": "node -e \"const fs=require('fs'),p=JSON.parse(fs.readFileSync('package.json','utf8'));p.version='{args.releaseVersion}';fs.writeFileSync('package.json',JSON.stringify(p,null,2)+'\\n');\""
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
2026-03-11 15:30:28 +00:00
}
},
chore: setup twenty-ui absolute path alias (#4732) Split from https://github.com/twentyhq/twenty/pull/4518 - Setup `@ui/*` as an internal alias to reference `twenty-ui/src`. - Configures twenty-front to understand the `@ui/*` alias on development mode, so twenty-ui can be hot reloaded. - When building on production mode, twenty-front needs twenty-ui to be built beforehand (which is automatic with the `dependsOn` option). - Configures twenty-front to understand the `@ui/*` alias when launching tests, so there is no need to re-build twenty-ui for tests. --------- Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
2024-04-04 13:38:01 +00:00
"storybook:build": {
fix: fix storybook pages tests coverage (#5319)
2024-05-07 19:05:45 +00:00
"executor": "nx:run-commands",
chore: setup twenty-ui absolute path alias (#4732) Split from https://github.com/twentyhq/twenty/pull/4518 - Setup `@ui/*` as an internal alias to reference `twenty-ui/src`. - Configures twenty-front to understand the `@ui/*` alias on development mode, so twenty-ui can be hot reloaded. - When building on production mode, twenty-front needs twenty-ui to be built beforehand (which is automatic with the `dependsOn` option). - Configures twenty-front to understand the `@ui/*` alias when launching tests, so there is no need to re-build twenty-ui for tests. --------- Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
2024-04-04 13:38:01 +00:00
"cache": true,
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.)
2026-01-17 06:37:17 +00:00
"inputs": ["^default", "excludeTests"],
"outputs": ["{projectRoot}/{options.output-dir}"],
chore: use Nx affected tasks in CI (#5110) Closes #5097 - Uses "nx affected" to detect what projects need to be checked in the current PR (for now, `ci-front` and `ci-server` workflows only). - Caches results of certain tasks (`lint`, `typecheck`, `test`, `storybook:build`) when a PR pipeline runs. The next runs of the same PR's pipeline will then be able to reuse the PR's task cache to execute tasks faster. - Caches Yarn's cache folder to install dependencies faster in CI jobs. - Rewrites the node modules cache/install steps as a custom, reusable Github action. - Distributes `ci-front` jobs with a "matrix" strategy. - Sets common tasks config at the root `nx.json`. For instance, to activate the `typecheck` task in a project, add `typecheck: {}` to its `project.json` and it'll use the default config set in `nx.json` for the `typecheck` task. Options can be overridden in each individual `project.json` if needed. - Adds "scope" tags to some projects: `scope:frontend`, `scope:backend`, `scope:shared`. An eslint rule ensures that `scope:frontend` only depends on `scope:frontent` or `scope:shared` projects, same for `scope:backend`. These tags are used by `nx affected` to filter projects by scope and generates different task cache keys according to the requested scope. - Enables checks for twenty-emails in the `ci-server` workflow.
2024-04-30 14:28:25 +00:00
"options": {
fix: fix storybook pages tests coverage (#5319)
2024-05-07 19:05:45 +00:00
"cwd": "{projectRoot}",
chore(front): remove vite-plugin-checker background TS/ESLint checks (#18437) ## Summary Removes `vite-plugin-checker` and all references to `VITE_DISABLE_TYPESCRIPT_CHECKER` / `VITE_DISABLE_ESLINT_CHECKER`. These background checks are no longer needed because our dev experience now relies on **independent** linters and type-checkers: - `npx nx lint:diff-with-main twenty-front` for ESLint - `npx nx typecheck twenty-front` for TypeScript Running these as separate processes (rather than inside Vite) is faster, gives cleaner output, and avoids the significant memory overhead that `vite-plugin-checker` introduces during `vite dev` and `vite build`. The old env vars to disable them are removed from `vite.config.ts`, `package.json` scripts, `nx.json`, `.env.example`, and all translated docs.
2026-03-05 17:55:04 +00:00
"command": "NODE_OPTIONS='--max-old-space-size=10240' storybook build --test",
fix: fix storybook pages tests coverage (#5319)
2024-05-07 19:05:45 +00:00
"output-dir": "storybook-static",
"config-dir": ".storybook"
Add Twenty Shared & Fix profile image rendering (#8841) PR Summary: 1. Added `Twenty Shared` Package to centralize utilitiies as mentioned in #8942 2. Optimization of `getImageAbsoluteURI.ts` to handle edge cases ![image](https://github.com/user-attachments/assets/c72a3061-6eba-46b8-85ac-869f06bf23c0) --------- Co-authored-by: Antoine Moreaux <moreaux.antoine@gmail.com> Co-authored-by: Charles Bochet <charles@twenty.com>
2024-12-17 08:24:21 +00:00
},
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.)
2026-01-17 06:37:17 +00:00
"dependsOn": ["^build"]
chore: setup twenty-ui absolute path alias (#4732) Split from https://github.com/twentyhq/twenty/pull/4518 - Setup `@ui/*` as an internal alias to reference `twenty-ui/src`. - Configures twenty-front to understand the `@ui/*` alias on development mode, so twenty-ui can be hot reloaded. - When building on production mode, twenty-front needs twenty-ui to be built beforehand (which is automatic with the `dependsOn` option). - Configures twenty-front to understand the `@ui/*` alias when launching tests, so there is no need to re-build twenty-ui for tests. --------- Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
2024-04-04 13:38:01 +00:00
},
Clarify storybook tests (#6073) In this PR, I'm simplifying storybook setup: 1) Remove build --test configuration that prevent autodocs. We are not using autodocs at all (the dev experience is not good enough), so I have completely disabled it. 2) Clarify `serve` vs `test` vs `serve-and-test` configurations After this PR: - you can serve storybook in two modes: `npx nx run twenty-front:storybook:serve:dev` and `npx nx run twenty-front:storybook:serve:static` - you can run tests agains an already served storybook (this is useful in dev so you don't have to rebuild everytime to run tests): `npx nx run twenty-front:storybook:test` - you can conbine both: `npx nx run twenty-front:storybook:serve-and-test:static`
2024-06-30 18:02:13 +00:00
"storybook:serve:dev": {
fix: fix storybook pages tests coverage (#5319)
2024-05-07 19:05:45 +00:00
"executor": "nx:run-commands",
chore: setup twenty-ui absolute path alias (#4732) Split from https://github.com/twentyhq/twenty/pull/4518 - Setup `@ui/*` as an internal alias to reference `twenty-ui/src`. - Configures twenty-front to understand the `@ui/*` alias on development mode, so twenty-ui can be hot reloaded. - When building on production mode, twenty-front needs twenty-ui to be built beforehand (which is automatic with the `dependsOn` option). - Configures twenty-front to understand the `@ui/*` alias when launching tests, so there is no need to re-build twenty-ui for tests. --------- Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
2024-04-04 13:38:01 +00:00
"cache": true,
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.)
2026-01-17 06:37:17 +00:00
"dependsOn": ["^build"],
chore: use Nx affected tasks in CI (#5110) Closes #5097 - Uses "nx affected" to detect what projects need to be checked in the current PR (for now, `ci-front` and `ci-server` workflows only). - Caches results of certain tasks (`lint`, `typecheck`, `test`, `storybook:build`) when a PR pipeline runs. The next runs of the same PR's pipeline will then be able to reuse the PR's task cache to execute tasks faster. - Caches Yarn's cache folder to install dependencies faster in CI jobs. - Rewrites the node modules cache/install steps as a custom, reusable Github action. - Distributes `ci-front` jobs with a "matrix" strategy. - Sets common tasks config at the root `nx.json`. For instance, to activate the `typecheck` task in a project, add `typecheck: {}` to its `project.json` and it'll use the default config set in `nx.json` for the `typecheck` task. Options can be overridden in each individual `project.json` if needed. - Adds "scope" tags to some projects: `scope:frontend`, `scope:backend`, `scope:shared`. An eslint rule ensures that `scope:frontend` only depends on `scope:frontent` or `scope:shared` projects, same for `scope:backend`. These tags are used by `nx affected` to filter projects by scope and generates different task cache keys according to the requested scope. - Enables checks for twenty-emails in the `ci-server` workflow.
2024-04-30 14:28:25 +00:00
"options": {
fix: fix storybook pages tests coverage (#5319)
2024-05-07 19:05:45 +00:00
"cwd": "{projectRoot}",
"command": "storybook dev",
"config-dir": ".storybook"
chore: use Nx affected tasks in CI (#5110) Closes #5097 - Uses "nx affected" to detect what projects need to be checked in the current PR (for now, `ci-front` and `ci-server` workflows only). - Caches results of certain tasks (`lint`, `typecheck`, `test`, `storybook:build`) when a PR pipeline runs. The next runs of the same PR's pipeline will then be able to reuse the PR's task cache to execute tasks faster. - Caches Yarn's cache folder to install dependencies faster in CI jobs. - Rewrites the node modules cache/install steps as a custom, reusable Github action. - Distributes `ci-front` jobs with a "matrix" strategy. - Sets common tasks config at the root `nx.json`. For instance, to activate the `typecheck` task in a project, add `typecheck: {}` to its `project.json` and it'll use the default config set in `nx.json` for the `typecheck` task. Options can be overridden in each individual `project.json` if needed. - Adds "scope" tags to some projects: `scope:frontend`, `scope:backend`, `scope:shared`. An eslint rule ensures that `scope:frontend` only depends on `scope:frontent` or `scope:shared` projects, same for `scope:backend`. These tags are used by `nx affected` to filter projects by scope and generates different task cache keys according to the requested scope. - Enables checks for twenty-emails in the `ci-server` workflow.
2024-04-30 14:28:25 +00:00
}
},
Clarify storybook tests (#6073) In this PR, I'm simplifying storybook setup: 1) Remove build --test configuration that prevent autodocs. We are not using autodocs at all (the dev experience is not good enough), so I have completely disabled it. 2) Clarify `serve` vs `test` vs `serve-and-test` configurations After this PR: - you can serve storybook in two modes: `npx nx run twenty-front:storybook:serve:dev` and `npx nx run twenty-front:storybook:serve:static` - you can run tests agains an already served storybook (this is useful in dev so you don't have to rebuild everytime to run tests): `npx nx run twenty-front:storybook:test` - you can conbine both: `npx nx run twenty-front:storybook:serve-and-test:static`
2024-06-30 18:02:13 +00:00
"storybook:serve:static": {
fix: fix storybook pages tests coverage (#5319)
2024-05-07 19:05:45 +00:00
"executor": "nx:run-commands",
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.)
2026-01-17 06:37:17 +00:00
"dependsOn": ["storybook:build"],
chore: use Nx affected tasks in CI (#5110) Closes #5097 - Uses "nx affected" to detect what projects need to be checked in the current PR (for now, `ci-front` and `ci-server` workflows only). - Caches results of certain tasks (`lint`, `typecheck`, `test`, `storybook:build`) when a PR pipeline runs. The next runs of the same PR's pipeline will then be able to reuse the PR's task cache to execute tasks faster. - Caches Yarn's cache folder to install dependencies faster in CI jobs. - Rewrites the node modules cache/install steps as a custom, reusable Github action. - Distributes `ci-front` jobs with a "matrix" strategy. - Sets common tasks config at the root `nx.json`. For instance, to activate the `typecheck` task in a project, add `typecheck: {}` to its `project.json` and it'll use the default config set in `nx.json` for the `typecheck` task. Options can be overridden in each individual `project.json` if needed. - Adds "scope" tags to some projects: `scope:frontend`, `scope:backend`, `scope:shared`. An eslint rule ensures that `scope:frontend` only depends on `scope:frontent` or `scope:shared` projects, same for `scope:backend`. These tags are used by `nx affected` to filter projects by scope and generates different task cache keys according to the requested scope. - Enables checks for twenty-emails in the `ci-server` workflow.
2024-04-30 14:28:25 +00:00
"options": {
fix: fix storybook pages tests coverage (#5319)
2024-05-07 19:05:45 +00:00
"cwd": "{projectRoot}",
"command": "npx http-server {args.staticDir} -a={args.host} --port={args.port} --silent={args.silent}",
"staticDir": "storybook-static",
"host": "localhost",
"port": 6006,
"silent": true
fix: fix storybook coverage task (#5256) - Fixes storybook coverage command: the coverage directory path was incorrect, but instead of failing `storybook:test --configuration=ci`, it was hanging indefinitely. - Switches back to `concurrently` to launch `storybook:static` and `storybook:test` in parallel, which allows to use options to explicitly kill `storybook:static` when `storybook:test` fails. - Moves `storybook:test --configuration=ci` to its own command `storybook:static:test`: used in the CI, and can be used locally to run storybook tests without having to launch `storybook:dev` first. - Creates command `storybook:coverage` and enables cache for this command. - Fixes Jest tests that were failing. - Improves caching conditions for some tasks (for instance, no need to invalidate Jest test cache if only Storybook story files were modified).
2024-05-03 12:59:09 +00:00
}
},
chore: use Nx affected tasks in CI (#5110) Closes #5097 - Uses "nx affected" to detect what projects need to be checked in the current PR (for now, `ci-front` and `ci-server` workflows only). - Caches results of certain tasks (`lint`, `typecheck`, `test`, `storybook:build`) when a PR pipeline runs. The next runs of the same PR's pipeline will then be able to reuse the PR's task cache to execute tasks faster. - Caches Yarn's cache folder to install dependencies faster in CI jobs. - Rewrites the node modules cache/install steps as a custom, reusable Github action. - Distributes `ci-front` jobs with a "matrix" strategy. - Sets common tasks config at the root `nx.json`. For instance, to activate the `typecheck` task in a project, add `typecheck: {}` to its `project.json` and it'll use the default config set in `nx.json` for the `typecheck` task. Options can be overridden in each individual `project.json` if needed. - Adds "scope" tags to some projects: `scope:frontend`, `scope:backend`, `scope:shared`. An eslint rule ensures that `scope:frontend` only depends on `scope:frontent` or `scope:shared` projects, same for `scope:backend`. These tags are used by `nx affected` to filter projects by scope and generates different task cache keys according to the requested scope. - Enables checks for twenty-emails in the `ci-server` workflow.
2024-04-30 14:28:25 +00:00
"storybook:test": {
"executor": "nx:run-commands",
fix: fix storybook coverage task (#5256) - Fixes storybook coverage command: the coverage directory path was incorrect, but instead of failing `storybook:test --configuration=ci`, it was hanging indefinitely. - Switches back to `concurrently` to launch `storybook:static` and `storybook:test` in parallel, which allows to use options to explicitly kill `storybook:static` when `storybook:test` fails. - Moves `storybook:test --configuration=ci` to its own command `storybook:static:test`: used in the CI, and can be used locally to run storybook tests without having to launch `storybook:dev` first. - Creates command `storybook:coverage` and enables cache for this command. - Fixes Jest tests that were failing. - Improves caching conditions for some tasks (for instance, no need to invalidate Jest test cache if only Storybook story files were modified).
2024-05-03 12:59:09 +00:00
"cache": true,
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.)
2026-01-17 06:37:17 +00:00
"inputs": ["^default", "excludeTests"],
"outputs": ["{projectRoot}/coverage/storybook"],
chore: use Nx affected tasks in CI (#5110) Closes #5097 - Uses "nx affected" to detect what projects need to be checked in the current PR (for now, `ci-front` and `ci-server` workflows only). - Caches results of certain tasks (`lint`, `typecheck`, `test`, `storybook:build`) when a PR pipeline runs. The next runs of the same PR's pipeline will then be able to reuse the PR's task cache to execute tasks faster. - Caches Yarn's cache folder to install dependencies faster in CI jobs. - Rewrites the node modules cache/install steps as a custom, reusable Github action. - Distributes `ci-front` jobs with a "matrix" strategy. - Sets common tasks config at the root `nx.json`. For instance, to activate the `typecheck` task in a project, add `typecheck: {}` to its `project.json` and it'll use the default config set in `nx.json` for the `typecheck` task. Options can be overridden in each individual `project.json` if needed. - Adds "scope" tags to some projects: `scope:frontend`, `scope:backend`, `scope:shared`. An eslint rule ensures that `scope:frontend` only depends on `scope:frontent` or `scope:shared` projects, same for `scope:backend`. These tags are used by `nx affected` to filter projects by scope and generates different task cache keys according to the requested scope. - Enables checks for twenty-emails in the `ci-server` workflow.
2024-04-30 14:28:25 +00:00
"options": {
fix: fix storybook coverage task (#5256) - Fixes storybook coverage command: the coverage directory path was incorrect, but instead of failing `storybook:test --configuration=ci`, it was hanging indefinitely. - Switches back to `concurrently` to launch `storybook:static` and `storybook:test` in parallel, which allows to use options to explicitly kill `storybook:static` when `storybook:test` fails. - Moves `storybook:test --configuration=ci` to its own command `storybook:static:test`: used in the CI, and can be used locally to run storybook tests without having to launch `storybook:dev` first. - Creates command `storybook:coverage` and enables cache for this command. - Fixes Jest tests that were failing. - Improves caching conditions for some tasks (for instance, no need to invalidate Jest test cache if only Storybook story files were modified).
2024-05-03 12:59:09 +00:00
"cwd": "{projectRoot}",
Replace test-runner with vitest for storybook (#17187)
2026-01-18 03:25:45 +00:00
"command": "vitest run --coverage --shard={args.shard}",
"shard": "1/1"
fix: fix storybook coverage task (#5256) - Fixes storybook coverage command: the coverage directory path was incorrect, but instead of failing `storybook:test --configuration=ci`, it was hanging indefinitely. - Switches back to `concurrently` to launch `storybook:static` and `storybook:test` in parallel, which allows to use options to explicitly kill `storybook:static` when `storybook:test` fails. - Moves `storybook:test --configuration=ci` to its own command `storybook:static:test`: used in the CI, and can be used locally to run storybook tests without having to launch `storybook:dev` first. - Creates command `storybook:coverage` and enables cache for this command. - Fixes Jest tests that were failing. - Improves caching conditions for some tasks (for instance, no need to invalidate Jest test cache if only Storybook story files were modified).
2024-05-03 12:59:09 +00:00
}
},
Clarify storybook tests (#6073) In this PR, I'm simplifying storybook setup: 1) Remove build --test configuration that prevent autodocs. We are not using autodocs at all (the dev experience is not good enough), so I have completely disabled it. 2) Clarify `serve` vs `test` vs `serve-and-test` configurations After this PR: - you can serve storybook in two modes: `npx nx run twenty-front:storybook:serve:dev` and `npx nx run twenty-front:storybook:serve:static` - you can run tests agains an already served storybook (this is useful in dev so you don't have to rebuild everytime to run tests): `npx nx run twenty-front:storybook:test` - you can conbine both: `npx nx run twenty-front:storybook:serve-and-test:static`
2024-06-30 18:02:13 +00:00
"storybook:test:no-coverage": {
Generic Profiling story to wrap any component (#5341) This PR introduces a Profiling feature for our story book tests. It also implements a new CI job : front-sb-test-performance, that only runs stories suffixed with `.perf.stories.tsx` ## How it works It allows to wrap any component into an array of React Profiler components that will run tests many times to have the most replicable average render time possible. It is simply used by calling the new `getProfilingStory` util. Internally it creates a defined number of tests, separated by an arbitrary waiting time to allow the CPU to give more stable results. It will do 3 warm-up and 3 finishing runs of tests because the first and last renders are always a bit erratic, so we want to measure only the runs in-between. On the UI side it gives a table of results : <img width="515" alt="image" src="https://github.com/twentyhq/twenty/assets/26528466/273d2d91-26da-437a-890e-778cb6c1f993"> On the programmatic side, it stores the result in a div that can then be parsed by the play fonction of storybook, to expect a defined threshold. ```tsx play: async ({ canvasElement }) => { await findByTestId( canvasElement, 'profiling-session-finished', {}, { timeout: 60000 }, ); const profilingReport = getProfilingReportFromDocument(canvasElement); if (!isDefined(profilingReport)) { return; } const p95result = profilingReport?.total.p95; expect( p95result, `Component render time is more than p95 threshold (${p95ThresholdInMs}ms)`, ).toBeLessThan(p95ThresholdInMs); }, ```
2024-05-15 11:50:02 +00:00
"executor": "nx:run-commands",
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.)
2026-01-17 06:37:17 +00:00
"inputs": ["^default", "excludeTests"],
Generic Profiling story to wrap any component (#5341) This PR introduces a Profiling feature for our story book tests. It also implements a new CI job : front-sb-test-performance, that only runs stories suffixed with `.perf.stories.tsx` ## How it works It allows to wrap any component into an array of React Profiler components that will run tests many times to have the most replicable average render time possible. It is simply used by calling the new `getProfilingStory` util. Internally it creates a defined number of tests, separated by an arbitrary waiting time to allow the CPU to give more stable results. It will do 3 warm-up and 3 finishing runs of tests because the first and last renders are always a bit erratic, so we want to measure only the runs in-between. On the UI side it gives a table of results : <img width="515" alt="image" src="https://github.com/twentyhq/twenty/assets/26528466/273d2d91-26da-437a-890e-778cb6c1f993"> On the programmatic side, it stores the result in a div that can then be parsed by the play fonction of storybook, to expect a defined threshold. ```tsx play: async ({ canvasElement }) => { await findByTestId( canvasElement, 'profiling-session-finished', {}, { timeout: 60000 }, ); const profilingReport = getProfilingReportFromDocument(canvasElement); if (!isDefined(profilingReport)) { return; } const p95result = profilingReport?.total.p95; expect( p95result, `Component render time is more than p95 threshold (${p95ThresholdInMs}ms)`, ).toBeLessThan(p95ThresholdInMs); }, ```
2024-05-15 11:50:02 +00:00
"options": {
"cwd": "{projectRoot}",
Replace test-runner with vitest for storybook (#17187)
2026-01-18 03:25:45 +00:00
"command": "vitest run --shard={args.shard}",
"shard": "1/1"
Generic Profiling story to wrap any component (#5341) This PR introduces a Profiling feature for our story book tests. It also implements a new CI job : front-sb-test-performance, that only runs stories suffixed with `.perf.stories.tsx` ## How it works It allows to wrap any component into an array of React Profiler components that will run tests many times to have the most replicable average render time possible. It is simply used by calling the new `getProfilingStory` util. Internally it creates a defined number of tests, separated by an arbitrary waiting time to allow the CPU to give more stable results. It will do 3 warm-up and 3 finishing runs of tests because the first and last renders are always a bit erratic, so we want to measure only the runs in-between. On the UI side it gives a table of results : <img width="515" alt="image" src="https://github.com/twentyhq/twenty/assets/26528466/273d2d91-26da-437a-890e-778cb6c1f993"> On the programmatic side, it stores the result in a div that can then be parsed by the play fonction of storybook, to expect a defined threshold. ```tsx play: async ({ canvasElement }) => { await findByTestId( canvasElement, 'profiling-session-finished', {}, { timeout: 60000 }, ); const profilingReport = getProfilingReportFromDocument(canvasElement); if (!isDefined(profilingReport)) { return; } const p95result = profilingReport?.total.p95; expect( p95result, `Component render time is more than p95 threshold (${p95ThresholdInMs}ms)`, ).toBeLessThan(p95ThresholdInMs); }, ```
2024-05-15 11:50:02 +00:00
}
},
Clarify storybook tests (#6073) In this PR, I'm simplifying storybook setup: 1) Remove build --test configuration that prevent autodocs. We are not using autodocs at all (the dev experience is not good enough), so I have completely disabled it. 2) Clarify `serve` vs `test` vs `serve-and-test` configurations After this PR: - you can serve storybook in two modes: `npx nx run twenty-front:storybook:serve:dev` and `npx nx run twenty-front:storybook:serve:static` - you can run tests agains an already served storybook (this is useful in dev so you don't have to rebuild everytime to run tests): `npx nx run twenty-front:storybook:test` - you can conbine both: `npx nx run twenty-front:storybook:serve-and-test:static`
2024-06-30 18:02:13 +00:00
"storybook:coverage": {
"executor": "nx:run-commands",
"cache": true,
"inputs": [
"^default",
"excludeTests",
"{projectRoot}/coverage/storybook/coverage-storybook.json"
],
"outputs": [
"{projectRoot}/coverage/storybook",
"!{projectRoot}/coverage/storybook/coverage-storybook.json"
],
"options": {
[CI][FRONT] Storybook tests sharding (#9448) # Introduction The idea here is to improve perf nor fluidity of both storybook build and tests execution duration. ## Levers: - Storybook tests [shards](https://storybook.js.org/docs/writing-tests/test-runner) - Refactored storybook's build caching using `actions/cache/restore` and `actions/cache/save` to avoid useless computation with we wanna just write or retrieve it - Running storybook build with --test [flag](https://storybook.js.org/docs/api/main-config/main-config-build) ( please note that we only disable docs addons in order to keep coverage up and running ) closes https://github.com/twentyhq/core-team-issues/issues/49
2025-01-10 17:40:03 +00:00
"command": "npx nyc report --reporter={args.reporter} --reporter=text-summary -t {args.coverageDir} --report-dir {args.coverageDir} --check-coverage={args.checkCoverage} --cwd={projectRoot}",
Clarify storybook tests (#6073) In this PR, I'm simplifying storybook setup: 1) Remove build --test configuration that prevent autodocs. We are not using autodocs at all (the dev experience is not good enough), so I have completely disabled it. 2) Clarify `serve` vs `test` vs `serve-and-test` configurations After this PR: - you can serve storybook in two modes: `npx nx run twenty-front:storybook:serve:dev` and `npx nx run twenty-front:storybook:serve:static` - you can run tests agains an already served storybook (this is useful in dev so you don't have to rebuild everytime to run tests): `npx nx run twenty-front:storybook:test` - you can conbine both: `npx nx run twenty-front:storybook:serve-and-test:static`
2024-06-30 18:02:13 +00:00
"coverageDir": "coverage/storybook",
[CI][FRONT] Storybook tests sharding (#9448) # Introduction The idea here is to improve perf nor fluidity of both storybook build and tests execution duration. ## Levers: - Storybook tests [shards](https://storybook.js.org/docs/writing-tests/test-runner) - Refactored storybook's build caching using `actions/cache/restore` and `actions/cache/save` to avoid useless computation with we wanna just write or retrieve it - Running storybook build with --test [flag](https://storybook.js.org/docs/api/main-config/main-config-build) ( please note that we only disable docs addons in order to keep coverage up and running ) closes https://github.com/twentyhq/core-team-issues/issues/49
2025-01-10 17:40:03 +00:00
"reporter": "lcov",
"checkCoverage": true
Clarify storybook tests (#6073) In this PR, I'm simplifying storybook setup: 1) Remove build --test configuration that prevent autodocs. We are not using autodocs at all (the dev experience is not good enough), so I have completely disabled it. 2) Clarify `serve` vs `test` vs `serve-and-test` configurations After this PR: - you can serve storybook in two modes: `npx nx run twenty-front:storybook:serve:dev` and `npx nx run twenty-front:storybook:serve:static` - you can run tests agains an already served storybook (this is useful in dev so you don't have to rebuild everytime to run tests): `npx nx run twenty-front:storybook:test` - you can conbine both: `npx nx run twenty-front:storybook:serve-and-test:static`
2024-06-30 18:02:13 +00:00
},
Refactor usePersistField (#13775) This PR introduces refactors and tradeoffs in the API around the events of field input. # Refactored usePersistField The hook `usePersistField` has been refactored to be used anywhere in the app, not just inside a FieldContext. This was meant to solve a bug at the beginning but now it is just used once in `RecordDetailRelationSection` outside of the context, still this is better to have this hook like that for future use cases. We also introduce `usePersistFieldFromFieldInputContext`, for an easier API inside a FieldContext. # Introduced a new `FieldInputEventContext` To remove the drill-down of events, we introduce `FieldInputEventContext`, this allows to set only once the handlers / events. In practice it allows to have an easier time maintaining the events for the many different field inputs, because it matches the pattern we already use of taking everything from a context (`FieldContext`). # Removed drill-down from FieldInput The heavy drill-down in FieldInput has been completely removed, since everything can be derived from `FieldContext` and `FieldInputEventContext`. Also there was some readonly and other specific props, but they were all drilled down from FieldContext, so it was easier to just use FieldContext where needed. # Refactored events of `MultiItemFieldInputProps` The component `MultiItemFieldInputProps` has a contrived API, here we just remove the complex part that was persisting from inside. We now only give a classic API with `onChange` and `onEscape` the rest is left to higher levels, where it should be, because this generic component shouldn't be aware of persisting things. # Extracted the parsing logic of persisted values For each input field component, we now have a clear util that was before bound to the persist call, # Tradeoff with persist times The tradeoff before was that persistField was called anywhere, before exiting the component sometimes, now it is only called by the higher levels like table or show page, which handles this abstraction. This could be challenged, however I think that having a lot of different events, and not just `handleSubmit` and `handleCancel`, convey enough meaning for the higher levels to decide what to do in each case. A `skipPersist` argument was added in events in the rare edge cases where we want to voluntarily skip persisting even with a submit or escape, but that could be challenged because we could also say that we should use cancel for that and stick to that convention. # Handling of the bug in `ActivityRichTextEditor` Initially this refactor was prioritized for solving this bug, which was very annoying for the users. But while fixing it with the new persistField hook I just understood that the problem is not just for record title cells but for anything that is open when we click on a rich text editor. The issue is described here : https://github.com/twentyhq/core-team-issues/issues/1317 So right now I just let it as is. # Stories The stories were checking that a request was sent in some cases where persist was called before a component exiting, now that persist is only called by higher-levels I just removed those tests from the stories, because that should be the responsibility of higher levels. Also a helper `getFieldInputEventContextProviderWithJestMocks` was created that exposes a context and jest mock functions for testing this new API in stories. # Miscellaneous Deactivated tui with nx by default, because it can be annoying.
2025-08-12 08:42:13 +00:00
"configurations": {
"text": {
"reporter": "text"
}
}
Clarify storybook tests (#6073) In this PR, I'm simplifying storybook setup: 1) Remove build --test configuration that prevent autodocs. We are not using autodocs at all (the dev experience is not good enough), so I have completely disabled it. 2) Clarify `serve` vs `test` vs `serve-and-test` configurations After this PR: - you can serve storybook in two modes: `npx nx run twenty-front:storybook:serve:dev` and `npx nx run twenty-front:storybook:serve:static` - you can run tests agains an already served storybook (this is useful in dev so you don't have to rebuild everytime to run tests): `npx nx run twenty-front:storybook:test` - you can conbine both: `npx nx run twenty-front:storybook:serve-and-test:static`
2024-06-30 18:02:13 +00:00
},
chore: use Nx affected tasks in CI (#5110) Closes #5097 - Uses "nx affected" to detect what projects need to be checked in the current PR (for now, `ci-front` and `ci-server` workflows only). - Caches results of certain tasks (`lint`, `typecheck`, `test`, `storybook:build`) when a PR pipeline runs. The next runs of the same PR's pipeline will then be able to reuse the PR's task cache to execute tasks faster. - Caches Yarn's cache folder to install dependencies faster in CI jobs. - Rewrites the node modules cache/install steps as a custom, reusable Github action. - Distributes `ci-front` jobs with a "matrix" strategy. - Sets common tasks config at the root `nx.json`. For instance, to activate the `typecheck` task in a project, add `typecheck: {}` to its `project.json` and it'll use the default config set in `nx.json` for the `typecheck` task. Options can be overridden in each individual `project.json` if needed. - Adds "scope" tags to some projects: `scope:frontend`, `scope:backend`, `scope:shared`. An eslint rule ensures that `scope:frontend` only depends on `scope:frontent` or `scope:shared` projects, same for `scope:backend`. These tags are used by `nx affected` to filter projects by scope and generates different task cache keys according to the requested scope. - Enables checks for twenty-emails in the `ci-server` workflow.
2024-04-30 14:28:25 +00:00
"chromatic": {
"executor": "nx:run-commands",
"options": {
"cwd": "{projectRoot}",
perf: use Nx cache for Chromatic script (#5457) Makes sure the `twenty-front:chromatic:ci` task in the CI job `front-chromatic-deployment` reuses the cache of the Storybook built in the CI job `front-sb-build` instead of re-building Storybook so Chromatic is deployed faster in the CI.
2024-05-22 09:18:16 +00:00
"commands": [
{
Clarify storybook tests (#6073) In this PR, I'm simplifying storybook setup: 1) Remove build --test configuration that prevent autodocs. We are not using autodocs at all (the dev experience is not good enough), so I have completely disabled it. 2) Clarify `serve` vs `test` vs `serve-and-test` configurations After this PR: - you can serve storybook in two modes: `npx nx run twenty-front:storybook:serve:dev` and `npx nx run twenty-front:storybook:serve:static` - you can run tests agains an already served storybook (this is useful in dev so you don't have to rebuild everytime to run tests): `npx nx run twenty-front:storybook:test` - you can conbine both: `npx nx run twenty-front:storybook:serve-and-test:static`
2024-06-30 18:02:13 +00:00
"command": "nx storybook:build {projectName}",
perf: use Nx cache for Chromatic script (#5457) Makes sure the `twenty-front:chromatic:ci` task in the CI job `front-chromatic-deployment` reuses the cache of the Storybook built in the CI job `front-sb-build` instead of re-building Storybook so Chromatic is deployed faster in the CI.
2024-05-22 09:18:16 +00:00
"forwardAllArgs": false
},
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.
2025-11-16 19:12:25 +00:00
"chromatic --storybook-build-dir=storybook-static {args.ci}"
perf: use Nx cache for Chromatic script (#5457) Makes sure the `twenty-front:chromatic:ci` task in the CI job `front-chromatic-deployment` reuses the cache of the Storybook built in the CI job `front-sb-build` instead of re-building Storybook so Chromatic is deployed faster in the CI.
2024-05-22 09:18:16 +00:00
],
"parallel": false
chore: use Nx affected tasks in CI (#5110) Closes #5097 - Uses "nx affected" to detect what projects need to be checked in the current PR (for now, `ci-front` and `ci-server` workflows only). - Caches results of certain tasks (`lint`, `typecheck`, `test`, `storybook:build`) when a PR pipeline runs. The next runs of the same PR's pipeline will then be able to reuse the PR's task cache to execute tasks faster. - Caches Yarn's cache folder to install dependencies faster in CI jobs. - Rewrites the node modules cache/install steps as a custom, reusable Github action. - Distributes `ci-front` jobs with a "matrix" strategy. - Sets common tasks config at the root `nx.json`. For instance, to activate the `typecheck` task in a project, add `typecheck: {}` to its `project.json` and it'll use the default config set in `nx.json` for the `typecheck` task. Options can be overridden in each individual `project.json` if needed. - Adds "scope" tags to some projects: `scope:frontend`, `scope:backend`, `scope:shared`. An eslint rule ensures that `scope:frontend` only depends on `scope:frontent` or `scope:shared` projects, same for `scope:backend`. These tags are used by `nx affected` to filter projects by scope and generates different task cache keys according to the requested scope. - Enables checks for twenty-emails in the `ci-server` workflow.
2024-04-30 14:28:25 +00:00
},
Refactor usePersistField (#13775) This PR introduces refactors and tradeoffs in the API around the events of field input. # Refactored usePersistField The hook `usePersistField` has been refactored to be used anywhere in the app, not just inside a FieldContext. This was meant to solve a bug at the beginning but now it is just used once in `RecordDetailRelationSection` outside of the context, still this is better to have this hook like that for future use cases. We also introduce `usePersistFieldFromFieldInputContext`, for an easier API inside a FieldContext. # Introduced a new `FieldInputEventContext` To remove the drill-down of events, we introduce `FieldInputEventContext`, this allows to set only once the handlers / events. In practice it allows to have an easier time maintaining the events for the many different field inputs, because it matches the pattern we already use of taking everything from a context (`FieldContext`). # Removed drill-down from FieldInput The heavy drill-down in FieldInput has been completely removed, since everything can be derived from `FieldContext` and `FieldInputEventContext`. Also there was some readonly and other specific props, but they were all drilled down from FieldContext, so it was easier to just use FieldContext where needed. # Refactored events of `MultiItemFieldInputProps` The component `MultiItemFieldInputProps` has a contrived API, here we just remove the complex part that was persisting from inside. We now only give a classic API with `onChange` and `onEscape` the rest is left to higher levels, where it should be, because this generic component shouldn't be aware of persisting things. # Extracted the parsing logic of persisted values For each input field component, we now have a clear util that was before bound to the persist call, # Tradeoff with persist times The tradeoff before was that persistField was called anywhere, before exiting the component sometimes, now it is only called by the higher levels like table or show page, which handles this abstraction. This could be challenged, however I think that having a lot of different events, and not just `handleSubmit` and `handleCancel`, convey enough meaning for the higher levels to decide what to do in each case. A `skipPersist` argument was added in events in the rare edge cases where we want to voluntarily skip persisting even with a submit or escape, but that could be challenged because we could also say that we should use cancel for that and stick to that convention. # Handling of the bug in `ActivityRichTextEditor` Initially this refactor was prioritized for solving this bug, which was very annoying for the users. But while fixing it with the new persistField hook I just understood that the problem is not just for record title cells but for anything that is open when we click on a rich text editor. The issue is described here : https://github.com/twentyhq/core-team-issues/issues/1317 So right now I just let it as is. # Stories The stories were checking that a request was sent in some cases where persist was called before a component exiting, now that persist is only called by higher-levels I just removed those tests from the stories, because that should be the responsibility of higher levels. Also a helper `getFieldInputEventContextProviderWithJestMocks` was created that exposes a context and jest mock functions for testing this new API in stories. # Miscellaneous Deactivated tui with nx by default, because it can be annoying.
2025-08-12 08:42:13 +00:00
"configurations": {
"ci": {
"ci": "--exit-zero-on-changes"
}
}
chore: setup twenty-ui absolute path alias (#4732) Split from https://github.com/twentyhq/twenty/pull/4518 - Setup `@ui/*` as an internal alias to reference `twenty-ui/src`. - Configures twenty-front to understand the `@ui/*` alias on development mode, so twenty-ui can be hot reloaded. - When building on production mode, twenty-front needs twenty-ui to be built beforehand (which is automatic with the `dependsOn` option). - Configures twenty-front to understand the `@ui/*` alias when launching tests, so there is no need to re-build twenty-ui for tests. --------- Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
2024-04-04 13:38:01 +00:00
},
POC: chore: use Nx workspace lint rules (#3163) * chore: use Nx workspace lint rules Closes #3162 * Fix lint * Fix lint on BE * Fix tests --------- Co-authored-by: Charles Bochet <charles@twenty.com>
2024-01-03 22:07:25 +00:00
"@nx/jest:jest": {
"cache": true,
fix: fix storybook coverage task (#5256) - Fixes storybook coverage command: the coverage directory path was incorrect, but instead of failing `storybook:test --configuration=ci`, it was hanging indefinitely. - Switches back to `concurrently` to launch `storybook:static` and `storybook:test` in parallel, which allows to use options to explicitly kill `storybook:static` when `storybook:test` fails. - Moves `storybook:test --configuration=ci` to its own command `storybook:static:test`: used in the CI, and can be used locally to run storybook tests without having to launch `storybook:dev` first. - Creates command `storybook:coverage` and enables cache for this command. - Fixes Jest tests that were failing. - Improves caching conditions for some tasks (for instance, no need to invalidate Jest test cache if only Storybook story files were modified).
2024-05-03 12:59:09 +00:00
"inputs": [
"^default",
"excludeStories",
"{workspaceRoot}/jest.preset.js"
],
Refactor usePersistField (#13775) This PR introduces refactors and tradeoffs in the API around the events of field input. # Refactored usePersistField The hook `usePersistField` has been refactored to be used anywhere in the app, not just inside a FieldContext. This was meant to solve a bug at the beginning but now it is just used once in `RecordDetailRelationSection` outside of the context, still this is better to have this hook like that for future use cases. We also introduce `usePersistFieldFromFieldInputContext`, for an easier API inside a FieldContext. # Introduced a new `FieldInputEventContext` To remove the drill-down of events, we introduce `FieldInputEventContext`, this allows to set only once the handlers / events. In practice it allows to have an easier time maintaining the events for the many different field inputs, because it matches the pattern we already use of taking everything from a context (`FieldContext`). # Removed drill-down from FieldInput The heavy drill-down in FieldInput has been completely removed, since everything can be derived from `FieldContext` and `FieldInputEventContext`. Also there was some readonly and other specific props, but they were all drilled down from FieldContext, so it was easier to just use FieldContext where needed. # Refactored events of `MultiItemFieldInputProps` The component `MultiItemFieldInputProps` has a contrived API, here we just remove the complex part that was persisting from inside. We now only give a classic API with `onChange` and `onEscape` the rest is left to higher levels, where it should be, because this generic component shouldn't be aware of persisting things. # Extracted the parsing logic of persisted values For each input field component, we now have a clear util that was before bound to the persist call, # Tradeoff with persist times The tradeoff before was that persistField was called anywhere, before exiting the component sometimes, now it is only called by the higher levels like table or show page, which handles this abstraction. This could be challenged, however I think that having a lot of different events, and not just `handleSubmit` and `handleCancel`, convey enough meaning for the higher levels to decide what to do in each case. A `skipPersist` argument was added in events in the rare edge cases where we want to voluntarily skip persisting even with a submit or escape, but that could be challenged because we could also say that we should use cancel for that and stick to that convention. # Handling of the bug in `ActivityRichTextEditor` Initially this refactor was prioritized for solving this bug, which was very annoying for the users. But while fixing it with the new persistField hook I just understood that the problem is not just for record title cells but for anything that is open when we click on a rich text editor. The issue is described here : https://github.com/twentyhq/core-team-issues/issues/1317 So right now I just let it as is. # Stories The stories were checking that a request was sent in some cases where persist was called before a component exiting, now that persist is only called by higher-levels I just removed those tests from the stories, because that should be the responsibility of higher levels. Also a helper `getFieldInputEventContextProviderWithJestMocks` was created that exposes a context and jest mock functions for testing this new API in stories. # Miscellaneous Deactivated tui with nx by default, because it can be annoying.
2025-08-12 08:42:13 +00:00
"options": {
"passWithNoTests": true
},
"configurations": {
"ci": {
"ci": true,
"codeCoverage": true
}
}
chore: set up twenty-emails config so build isn't needed in development (#3619) * chore: set up twenty-emails config so build isn't needed in development * fix: fix script dependency * chore: use @vitejs/plugin-react-swc * Remove useless dependancy * Fix typing * chore: use baseUrl in twenty-emails * chore: fix docker server prod build * refactor: optimize Docker file and tsconfig * fix: fix WORKDIR in docker --------- Co-authored-by: martmull <martmull@hotmail.fr>
2024-01-29 09:17:12 +00:00
},
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.)
2026-01-17 06:37:17 +00:00
"@nx/vite:build": {
Refactor usePersistField (#13775) This PR introduces refactors and tradeoffs in the API around the events of field input. # Refactored usePersistField The hook `usePersistField` has been refactored to be used anywhere in the app, not just inside a FieldContext. This was meant to solve a bug at the beginning but now it is just used once in `RecordDetailRelationSection` outside of the context, still this is better to have this hook like that for future use cases. We also introduce `usePersistFieldFromFieldInputContext`, for an easier API inside a FieldContext. # Introduced a new `FieldInputEventContext` To remove the drill-down of events, we introduce `FieldInputEventContext`, this allows to set only once the handlers / events. In practice it allows to have an easier time maintaining the events for the many different field inputs, because it matches the pattern we already use of taking everything from a context (`FieldContext`). # Removed drill-down from FieldInput The heavy drill-down in FieldInput has been completely removed, since everything can be derived from `FieldContext` and `FieldInputEventContext`. Also there was some readonly and other specific props, but they were all drilled down from FieldContext, so it was easier to just use FieldContext where needed. # Refactored events of `MultiItemFieldInputProps` The component `MultiItemFieldInputProps` has a contrived API, here we just remove the complex part that was persisting from inside. We now only give a classic API with `onChange` and `onEscape` the rest is left to higher levels, where it should be, because this generic component shouldn't be aware of persisting things. # Extracted the parsing logic of persisted values For each input field component, we now have a clear util that was before bound to the persist call, # Tradeoff with persist times The tradeoff before was that persistField was called anywhere, before exiting the component sometimes, now it is only called by the higher levels like table or show page, which handles this abstraction. This could be challenged, however I think that having a lot of different events, and not just `handleSubmit` and `handleCancel`, convey enough meaning for the higher levels to decide what to do in each case. A `skipPersist` argument was added in events in the rare edge cases where we want to voluntarily skip persisting even with a submit or escape, but that could be challenged because we could also say that we should use cancel for that and stick to that convention. # Handling of the bug in `ActivityRichTextEditor` Initially this refactor was prioritized for solving this bug, which was very annoying for the users. But while fixing it with the new persistField hook I just understood that the problem is not just for record title cells but for anything that is open when we click on a rich text editor. The issue is described here : https://github.com/twentyhq/core-team-issues/issues/1317 So right now I just let it as is. # Stories The stories were checking that a request was sent in some cases where persist was called before a component exiting, now that persist is only called by higher-levels I just removed those tests from the stories, because that should be the responsibility of higher levels. Also a helper `getFieldInputEventContextProviderWithJestMocks` was created that exposes a context and jest mock functions for testing this new API in stories. # Miscellaneous Deactivated tui with nx by default, because it can be annoying.
2025-08-12 08:42:13 +00:00
"cache": true,
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.)
2026-01-17 06:37:17 +00:00
"dependsOn": ["^build"],
"inputs": ["default", "^default"]
Refactor usePersistField (#13775) This PR introduces refactors and tradeoffs in the API around the events of field input. # Refactored usePersistField The hook `usePersistField` has been refactored to be used anywhere in the app, not just inside a FieldContext. This was meant to solve a bug at the beginning but now it is just used once in `RecordDetailRelationSection` outside of the context, still this is better to have this hook like that for future use cases. We also introduce `usePersistFieldFromFieldInputContext`, for an easier API inside a FieldContext. # Introduced a new `FieldInputEventContext` To remove the drill-down of events, we introduce `FieldInputEventContext`, this allows to set only once the handlers / events. In practice it allows to have an easier time maintaining the events for the many different field inputs, because it matches the pattern we already use of taking everything from a context (`FieldContext`). # Removed drill-down from FieldInput The heavy drill-down in FieldInput has been completely removed, since everything can be derived from `FieldContext` and `FieldInputEventContext`. Also there was some readonly and other specific props, but they were all drilled down from FieldContext, so it was easier to just use FieldContext where needed. # Refactored events of `MultiItemFieldInputProps` The component `MultiItemFieldInputProps` has a contrived API, here we just remove the complex part that was persisting from inside. We now only give a classic API with `onChange` and `onEscape` the rest is left to higher levels, where it should be, because this generic component shouldn't be aware of persisting things. # Extracted the parsing logic of persisted values For each input field component, we now have a clear util that was before bound to the persist call, # Tradeoff with persist times The tradeoff before was that persistField was called anywhere, before exiting the component sometimes, now it is only called by the higher levels like table or show page, which handles this abstraction. This could be challenged, however I think that having a lot of different events, and not just `handleSubmit` and `handleCancel`, convey enough meaning for the higher levels to decide what to do in each case. A `skipPersist` argument was added in events in the rare edge cases where we want to voluntarily skip persisting even with a submit or escape, but that could be challenged because we could also say that we should use cancel for that and stick to that convention. # Handling of the bug in `ActivityRichTextEditor` Initially this refactor was prioritized for solving this bug, which was very annoying for the users. But while fixing it with the new persistField hook I just understood that the problem is not just for record title cells but for anything that is open when we click on a rich text editor. The issue is described here : https://github.com/twentyhq/core-team-issues/issues/1317 So right now I just let it as is. # Stories The stories were checking that a request was sent in some cases where persist was called before a component exiting, now that persist is only called by higher-levels I just removed those tests from the stories, because that should be the responsibility of higher levels. Also a helper `getFieldInputEventContextProviderWithJestMocks` was created that exposes a context and jest mock functions for testing this new API in stories. # Miscellaneous Deactivated tui with nx by default, because it can be annoying.
2025-08-12 08:42:13 +00:00
},
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.)
2026-01-17 06:37:17 +00:00
"@nx/vitest:test": {
chore: include react components in twenty-ui test config (#4709) Split from https://github.com/twentyhq/twenty/pull/4518 Part of https://github.com/twentyhq/twenty/issues/4766 - Re-generates some of the twenty-ui test and storybook config with Nx - Includes tsx files in twenty-ui tests and compiles them with swc --------- Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
2024-04-04 10:30:49 +00:00
"cache": true,
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.)
2026-01-17 06:37:17 +00:00
"inputs": ["default", "^default"]
Migrate to a monorepo structure (#2909)
2023-12-10 17:10:54 +00:00
}
},
chore: set up twenty-emails config so build isn't needed in development (#3619) * chore: set up twenty-emails config so build isn't needed in development * fix: fix script dependency * chore: use @vitejs/plugin-react-swc * Remove useless dependancy * Fix typing * chore: use baseUrl in twenty-emails * chore: fix docker server prod build * refactor: optimize Docker file and tsconfig * fix: fix WORKDIR in docker --------- Co-authored-by: martmull <martmull@hotmail.fr>
2024-01-29 09:17:12 +00:00
"generators": {
"@nx/react": {
"application": {
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()`
2026-03-03 23:50:06 +00:00
"style": "@linaria/react",
chore: setup twenty-ui absolute path alias (#4732) Split from https://github.com/twentyhq/twenty/pull/4518 - Setup `@ui/*` as an internal alias to reference `twenty-ui/src`. - Configures twenty-front to understand the `@ui/*` alias on development mode, so twenty-ui can be hot reloaded. - When building on production mode, twenty-front needs twenty-ui to be built beforehand (which is automatic with the `dependsOn` option). - Configures twenty-front to understand the `@ui/*` alias when launching tests, so there is no need to re-build twenty-ui for tests. --------- Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
2024-04-04 13:38:01 +00:00
"bundler": "vite",
"compiler": "swc",
"unitTestRunner": "jest",
"projectNameAndRootFormat": "derived"
chore: set up twenty-emails config so build isn't needed in development (#3619) * chore: set up twenty-emails config so build isn't needed in development * fix: fix script dependency * chore: use @vitejs/plugin-react-swc * Remove useless dependancy * Fix typing * chore: use baseUrl in twenty-emails * chore: fix docker server prod build * refactor: optimize Docker file and tsconfig * fix: fix WORKDIR in docker --------- Co-authored-by: martmull <martmull@hotmail.fr>
2024-01-29 09:17:12 +00:00
},
"library": {
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()`
2026-03-03 23:50:06 +00:00
"style": "@linaria/react",
chore: setup twenty-ui absolute path alias (#4732) Split from https://github.com/twentyhq/twenty/pull/4518 - Setup `@ui/*` as an internal alias to reference `twenty-ui/src`. - Configures twenty-front to understand the `@ui/*` alias on development mode, so twenty-ui can be hot reloaded. - When building on production mode, twenty-front needs twenty-ui to be built beforehand (which is automatic with the `dependsOn` option). - Configures twenty-front to understand the `@ui/*` alias when launching tests, so there is no need to re-build twenty-ui for tests. --------- Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
2024-04-04 13:38:01 +00:00
"bundler": "vite",
"compiler": "swc",
"unitTestRunner": "jest",
"projectNameAndRootFormat": "derived"
},
Refactor usePersistField (#13775) This PR introduces refactors and tradeoffs in the API around the events of field input. # Refactored usePersistField The hook `usePersistField` has been refactored to be used anywhere in the app, not just inside a FieldContext. This was meant to solve a bug at the beginning but now it is just used once in `RecordDetailRelationSection` outside of the context, still this is better to have this hook like that for future use cases. We also introduce `usePersistFieldFromFieldInputContext`, for an easier API inside a FieldContext. # Introduced a new `FieldInputEventContext` To remove the drill-down of events, we introduce `FieldInputEventContext`, this allows to set only once the handlers / events. In practice it allows to have an easier time maintaining the events for the many different field inputs, because it matches the pattern we already use of taking everything from a context (`FieldContext`). # Removed drill-down from FieldInput The heavy drill-down in FieldInput has been completely removed, since everything can be derived from `FieldContext` and `FieldInputEventContext`. Also there was some readonly and other specific props, but they were all drilled down from FieldContext, so it was easier to just use FieldContext where needed. # Refactored events of `MultiItemFieldInputProps` The component `MultiItemFieldInputProps` has a contrived API, here we just remove the complex part that was persisting from inside. We now only give a classic API with `onChange` and `onEscape` the rest is left to higher levels, where it should be, because this generic component shouldn't be aware of persisting things. # Extracted the parsing logic of persisted values For each input field component, we now have a clear util that was before bound to the persist call, # Tradeoff with persist times The tradeoff before was that persistField was called anywhere, before exiting the component sometimes, now it is only called by the higher levels like table or show page, which handles this abstraction. This could be challenged, however I think that having a lot of different events, and not just `handleSubmit` and `handleCancel`, convey enough meaning for the higher levels to decide what to do in each case. A `skipPersist` argument was added in events in the rare edge cases where we want to voluntarily skip persisting even with a submit or escape, but that could be challenged because we could also say that we should use cancel for that and stick to that convention. # Handling of the bug in `ActivityRichTextEditor` Initially this refactor was prioritized for solving this bug, which was very annoying for the users. But while fixing it with the new persistField hook I just understood that the problem is not just for record title cells but for anything that is open when we click on a rich text editor. The issue is described here : https://github.com/twentyhq/core-team-issues/issues/1317 So right now I just let it as is. # Stories The stories were checking that a request was sent in some cases where persist was called before a component exiting, now that persist is only called by higher-levels I just removed those tests from the stories, because that should be the responsibility of higher levels. Also a helper `getFieldInputEventContextProviderWithJestMocks` was created that exposes a context and jest mock functions for testing this new API in stories. # Miscellaneous Deactivated tui with nx by default, because it can be annoying.
2025-08-12 08:42:13 +00:00
"component": {
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()`
2026-03-03 23:50:06 +00:00
"style": "@linaria/react"
Refactor usePersistField (#13775) This PR introduces refactors and tradeoffs in the API around the events of field input. # Refactored usePersistField The hook `usePersistField` has been refactored to be used anywhere in the app, not just inside a FieldContext. This was meant to solve a bug at the beginning but now it is just used once in `RecordDetailRelationSection` outside of the context, still this is better to have this hook like that for future use cases. We also introduce `usePersistFieldFromFieldInputContext`, for an easier API inside a FieldContext. # Introduced a new `FieldInputEventContext` To remove the drill-down of events, we introduce `FieldInputEventContext`, this allows to set only once the handlers / events. In practice it allows to have an easier time maintaining the events for the many different field inputs, because it matches the pattern we already use of taking everything from a context (`FieldContext`). # Removed drill-down from FieldInput The heavy drill-down in FieldInput has been completely removed, since everything can be derived from `FieldContext` and `FieldInputEventContext`. Also there was some readonly and other specific props, but they were all drilled down from FieldContext, so it was easier to just use FieldContext where needed. # Refactored events of `MultiItemFieldInputProps` The component `MultiItemFieldInputProps` has a contrived API, here we just remove the complex part that was persisting from inside. We now only give a classic API with `onChange` and `onEscape` the rest is left to higher levels, where it should be, because this generic component shouldn't be aware of persisting things. # Extracted the parsing logic of persisted values For each input field component, we now have a clear util that was before bound to the persist call, # Tradeoff with persist times The tradeoff before was that persistField was called anywhere, before exiting the component sometimes, now it is only called by the higher levels like table or show page, which handles this abstraction. This could be challenged, however I think that having a lot of different events, and not just `handleSubmit` and `handleCancel`, convey enough meaning for the higher levels to decide what to do in each case. A `skipPersist` argument was added in events in the rare edge cases where we want to voluntarily skip persisting even with a submit or escape, but that could be challenged because we could also say that we should use cancel for that and stick to that convention. # Handling of the bug in `ActivityRichTextEditor` Initially this refactor was prioritized for solving this bug, which was very annoying for the users. But while fixing it with the new persistField hook I just understood that the problem is not just for record title cells but for anything that is open when we click on a rich text editor. The issue is described here : https://github.com/twentyhq/core-team-issues/issues/1317 So right now I just let it as is. # Stories The stories were checking that a request was sent in some cases where persist was called before a component exiting, now that persist is only called by higher-levels I just removed those tests from the stories, because that should be the responsibility of higher levels. Also a helper `getFieldInputEventContextProviderWithJestMocks` was created that exposes a context and jest mock functions for testing this new API in stories. # Miscellaneous Deactivated tui with nx by default, because it can be annoying.
2025-08-12 08:42:13 +00:00
}
chore: set up twenty-emails config so build isn't needed in development (#3619) * chore: set up twenty-emails config so build isn't needed in development * fix: fix script dependency * chore: use @vitejs/plugin-react-swc * Remove useless dependancy * Fix typing * chore: use baseUrl in twenty-emails * chore: fix docker server prod build * refactor: optimize Docker file and tsconfig * fix: fix WORKDIR in docker --------- Co-authored-by: martmull <martmull@hotmail.fr>
2024-01-29 09:17:12 +00:00
}
Setup the foundation for Twenty UI library. (#4423) * feat: create a separate package for twenty-ui, extract the pill component with hard-coded theme values into it, and use the component inside twenty-front to complete the setup * feat: extract the light and the dark theme into twenty-ui and update the AppThemeProvider component inside twenty-front to consume themes from twenty-ui * fix: create a decorator inside preview.tsx to provide a default theme to storybook development server * fix: remove redundant type declarations and revert back the naming convention for theme declarations * fix: introduce a default value for pill label within the story for development server * fix: introduce the nx script into package.json for twenty-ui and resolve imports for theme type within the package * fix: remove the pill component from the twenty-front package along with the story for it * fix: revert the package versions to those before running the nx cli command for storybook init * feat: update readme to include details for building the ui library and starting the storybook development server * fix: include details about twenty-ui inside jest.config for twenty-front to complete front-jest job * - Added preview head for font - Added theme addon for light/dark switch - Added ComponentDecorator --------- Co-authored-by: Lucas Bordeau <bordeau.lucas@gmail.com>
2024-03-13 13:21:18 +00:00
},
"tasksRunnerOptions": {
Refactor usePersistField (#13775) This PR introduces refactors and tradeoffs in the API around the events of field input. # Refactored usePersistField The hook `usePersistField` has been refactored to be used anywhere in the app, not just inside a FieldContext. This was meant to solve a bug at the beginning but now it is just used once in `RecordDetailRelationSection` outside of the context, still this is better to have this hook like that for future use cases. We also introduce `usePersistFieldFromFieldInputContext`, for an easier API inside a FieldContext. # Introduced a new `FieldInputEventContext` To remove the drill-down of events, we introduce `FieldInputEventContext`, this allows to set only once the handlers / events. In practice it allows to have an easier time maintaining the events for the many different field inputs, because it matches the pattern we already use of taking everything from a context (`FieldContext`). # Removed drill-down from FieldInput The heavy drill-down in FieldInput has been completely removed, since everything can be derived from `FieldContext` and `FieldInputEventContext`. Also there was some readonly and other specific props, but they were all drilled down from FieldContext, so it was easier to just use FieldContext where needed. # Refactored events of `MultiItemFieldInputProps` The component `MultiItemFieldInputProps` has a contrived API, here we just remove the complex part that was persisting from inside. We now only give a classic API with `onChange` and `onEscape` the rest is left to higher levels, where it should be, because this generic component shouldn't be aware of persisting things. # Extracted the parsing logic of persisted values For each input field component, we now have a clear util that was before bound to the persist call, # Tradeoff with persist times The tradeoff before was that persistField was called anywhere, before exiting the component sometimes, now it is only called by the higher levels like table or show page, which handles this abstraction. This could be challenged, however I think that having a lot of different events, and not just `handleSubmit` and `handleCancel`, convey enough meaning for the higher levels to decide what to do in each case. A `skipPersist` argument was added in events in the rare edge cases where we want to voluntarily skip persisting even with a submit or escape, but that could be challenged because we could also say that we should use cancel for that and stick to that convention. # Handling of the bug in `ActivityRichTextEditor` Initially this refactor was prioritized for solving this bug, which was very annoying for the users. But while fixing it with the new persistField hook I just understood that the problem is not just for record title cells but for anything that is open when we click on a rich text editor. The issue is described here : https://github.com/twentyhq/core-team-issues/issues/1317 So right now I just let it as is. # Stories The stories were checking that a request was sent in some cases where persist was called before a component exiting, now that persist is only called by higher-levels I just removed those tests from the stories, because that should be the responsibility of higher levels. Also a helper `getFieldInputEventContextProviderWithJestMocks` was created that exposes a context and jest mock functions for testing this new API in stories. # Miscellaneous Deactivated tui with nx by default, because it can be annoying.
2025-08-12 08:42:13 +00:00
"default": {
"options": {
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.)
2026-01-17 06:37:17 +00:00
"cacheableOperations": ["storybook:build"]
Refactor usePersistField (#13775) This PR introduces refactors and tradeoffs in the API around the events of field input. # Refactored usePersistField The hook `usePersistField` has been refactored to be used anywhere in the app, not just inside a FieldContext. This was meant to solve a bug at the beginning but now it is just used once in `RecordDetailRelationSection` outside of the context, still this is better to have this hook like that for future use cases. We also introduce `usePersistFieldFromFieldInputContext`, for an easier API inside a FieldContext. # Introduced a new `FieldInputEventContext` To remove the drill-down of events, we introduce `FieldInputEventContext`, this allows to set only once the handlers / events. In practice it allows to have an easier time maintaining the events for the many different field inputs, because it matches the pattern we already use of taking everything from a context (`FieldContext`). # Removed drill-down from FieldInput The heavy drill-down in FieldInput has been completely removed, since everything can be derived from `FieldContext` and `FieldInputEventContext`. Also there was some readonly and other specific props, but they were all drilled down from FieldContext, so it was easier to just use FieldContext where needed. # Refactored events of `MultiItemFieldInputProps` The component `MultiItemFieldInputProps` has a contrived API, here we just remove the complex part that was persisting from inside. We now only give a classic API with `onChange` and `onEscape` the rest is left to higher levels, where it should be, because this generic component shouldn't be aware of persisting things. # Extracted the parsing logic of persisted values For each input field component, we now have a clear util that was before bound to the persist call, # Tradeoff with persist times The tradeoff before was that persistField was called anywhere, before exiting the component sometimes, now it is only called by the higher levels like table or show page, which handles this abstraction. This could be challenged, however I think that having a lot of different events, and not just `handleSubmit` and `handleCancel`, convey enough meaning for the higher levels to decide what to do in each case. A `skipPersist` argument was added in events in the rare edge cases where we want to voluntarily skip persisting even with a submit or escape, but that could be challenged because we could also say that we should use cancel for that and stick to that convention. # Handling of the bug in `ActivityRichTextEditor` Initially this refactor was prioritized for solving this bug, which was very annoying for the users. But while fixing it with the new persistField hook I just understood that the problem is not just for record title cells but for anything that is open when we click on a rich text editor. The issue is described here : https://github.com/twentyhq/core-team-issues/issues/1317 So right now I just let it as is. # Stories The stories were checking that a request was sent in some cases where persist was called before a component exiting, now that persist is only called by higher-levels I just removed those tests from the stories, because that should be the responsibility of higher levels. Also a helper `getFieldInputEventContextProviderWithJestMocks` was created that exposes a context and jest mock functions for testing this new API in stories. # Miscellaneous Deactivated tui with nx by default, because it can be annoying.
2025-08-12 08:42:13 +00:00
}
}
chore: upgrade Nx to v18.1.3 (#4706) Split from https://github.com/twentyhq/twenty/pull/4518 - Upgrades dependencies and applies automatic config migrations with the command: `npx nx migrate nx` (see https://nx.dev/nx-api/nx/documents/migrate) - Fixes lint errors after upgrading `@typescript-eslint` Note: it was not possible (for now) to migrate Nx to the latest stable version (v18.2.1) because it upgrades Typescript to v5.4.3, which seems to cause a bug on install when Yarn tries to apply its native patches. Might be a bug on the Yarn side.
2024-04-01 11:16:50 +00:00
},
"useInferencePlugins": false,
Disable nx ui terminal (#13910) Disable nx ui terminal: https://nx.dev/recipes/running-tasks/terminal-ui#enabledisable-the-terminal-ui
2025-08-13 15:50:10 +00:00
"defaultBase": "main",
"tui": {
"enabled": false
}
Refactor read only object and fields (#13936) Co-authored-by: Charles Bochet <charles@twenty.com>
2025-08-19 16:10:35 +00:00
}
Reference in a new issue Copy permalink