twenty/packages/twenty-front/project.json

149 lines
4.2 KiB
JSON
Raw Normal View History

{
"name": "twenty-front",
"$schema": "../../node_modules/nx/schemas/project-schema.json",
"projectType": "application",
"tags": ["scope:frontend"],
"targets": {
"build": {
"outputs": ["{options.outputPath}"],
"options": {
"outputPath": "{projectRoot}/build"
}
},
"start": {
"executor": "@nx/vite:dev-server",
"options": {
"buildTarget": "twenty-front:build",
"hmr": true
}
},
"preview": {
"executor": "@nx/vite:preview-server",
"options": {
"buildTarget": "twenty-front:build",
"port": 3001,
"open": true
}
},
"reset:env": {
"executor": "nx:run-commands",
"inputs": ["{projectRoot}/.env.example"],
"outputs": ["{projectRoot}/.env"],
"cache": true,
"options": {
"cwd": "{projectRoot}",
"command": "cp .env.example .env"
}
},
"typecheck": {},
"lint": {
"options": {
"lintFilePatterns": [
"{projectRoot}/src/**/*.{ts,tsx,json}",
"{projectRoot}/package.json"
],
"maxWarnings": 0,
"reportUnusedDisableDirectives": "error"
},
"configurations": {
"ci": { "eslintConfig": "{projectRoot}/.eslintrc-ci.cjs" },
"fix": {}
}
},
"fmt": {
"options": {
"files": "src"
},
"configurations": {
"fix": {}
}
},
"test": {},
"storybook:build": {
"options": {
"env": { "NODE_OPTIONS": "--max_old_space_size=5000" }
},
"configurations": {
fix: fix storybook build cache not being used by tests in CI (#5451) TL;DR: - removed `--configuration={args.scope}` from `storybook:static:test` for the `storybook:static` part, as it was making `front-sb-test` jobs in CI not reuse the cache from the `front-sb-build` job and re-build storybook every time. - replaced it with a new `test` configuration which optimizes storybook build for tests and builds storybook 2x faster. ## Fix storybook:build cache usage in CI `storybook:static:test` executes two scripts in parallel: 1. `storybook:static`, which depends on `storybook:build` 1.a. it builds storybook first with `storybook:build`, the output directory is `storybook-static`. 1.b. then it launches an `http-server`, using what has been built in `storybook-static` 2. `storybook:test` to execute tests (needs the storybook http-server to be running) When passing `--configuration=pages` or `--configuration=modules` to `storybook:static` from step 1, those configurations are passed to the `storybook:build` script from step 1.a as well. But for Nx `storybook:build` and `storybook:build --configuration=pages` (or `modules`) are not the same command, therefore one does not reuse the cache of the other because they could output completely different things. As `front-sb-test` jobs are passing `--configuration={args.scope}` to `storybook:static`, the cache of the previously executed `storybook:build` (from `front-sb-build`) is not reused and therefore each job re-builds Storybook with its own scope, which increases CI time. ### Solution - Removed scope configurations from `storybook:static` and `storybook:build` scripts to avoid confusion. - `storybook:test` and `storybook:dev` can keep scope configurations as they can be useful and this doesn't impact storybook build cache in CI. ### Improve Storybook build time for testing Added the `test` configuration to `storybook:build` and `storybook:static` which makes Storybook build time 2x faster. It disables addons that slow down build time and are not used in tests.
2024-05-17 17:05:31 +03:00
"test": {}
}
},
"storybook:dev": {
"options": { "port": 6006 },
"configurations": {
"docs": { "env": { "STORYBOOK_SCOPE": "ui-docs" } },
"modules": { "env": { "STORYBOOK_SCOPE": "modules" } },
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 14:50:02 +03:00
"pages": { "env": { "STORYBOOK_SCOPE": "pages" } },
"performance": { "env": { "STORYBOOK_SCOPE": "performance" } }
}
},
"storybook:static": {
"options": { "port": 6006 },
"configurations": {
fix: fix storybook build cache not being used by tests in CI (#5451) TL;DR: - removed `--configuration={args.scope}` from `storybook:static:test` for the `storybook:static` part, as it was making `front-sb-test` jobs in CI not reuse the cache from the `front-sb-build` job and re-build storybook every time. - replaced it with a new `test` configuration which optimizes storybook build for tests and builds storybook 2x faster. ## Fix storybook:build cache usage in CI `storybook:static:test` executes two scripts in parallel: 1. `storybook:static`, which depends on `storybook:build` 1.a. it builds storybook first with `storybook:build`, the output directory is `storybook-static`. 1.b. then it launches an `http-server`, using what has been built in `storybook-static` 2. `storybook:test` to execute tests (needs the storybook http-server to be running) When passing `--configuration=pages` or `--configuration=modules` to `storybook:static` from step 1, those configurations are passed to the `storybook:build` script from step 1.a as well. But for Nx `storybook:build` and `storybook:build --configuration=pages` (or `modules`) are not the same command, therefore one does not reuse the cache of the other because they could output completely different things. As `front-sb-test` jobs are passing `--configuration={args.scope}` to `storybook:static`, the cache of the previously executed `storybook:build` (from `front-sb-build`) is not reused and therefore each job re-builds Storybook with its own scope, which increases CI time. ### Solution - Removed scope configurations from `storybook:static` and `storybook:build` scripts to avoid confusion. - `storybook:test` and `storybook:dev` can keep scope configurations as they can be useful and this doesn't impact storybook build cache in CI. ### Improve Storybook build time for testing Added the `test` configuration to `storybook:build` and `storybook:static` which makes Storybook build time 2x faster. It disables addons that slow down build time and are not used in tests.
2024-05-17 17:05:31 +03:00
"test": {}
}
},
"storybook:coverage": {
"configurations": {
"text": {},
"docs": { "env": { "STORYBOOK_SCOPE": "ui-docs" } },
"modules": { "env": { "STORYBOOK_SCOPE": "modules" } },
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 14:50:02 +03:00
"pages": { "env": { "STORYBOOK_SCOPE": "pages" } },
"performance": { "env": { "STORYBOOK_SCOPE": "performance" } }
}
},
"storybook:test": {
"options": { "port": 6006 },
"configurations": {
"docs": { "env": { "STORYBOOK_SCOPE": "ui-docs" } },
"modules": { "env": { "STORYBOOK_SCOPE": "modules" } },
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 14:50:02 +03:00
"pages": { "env": { "STORYBOOK_SCOPE": "pages" } },
"performance": { "env": { "STORYBOOK_SCOPE": "performance" } }
}
},
"storybook:test:nocoverage": {
"configurations": {
"docs": { "env": { "STORYBOOK_SCOPE": "ui-docs" } },
"modules": { "env": { "STORYBOOK_SCOPE": "modules" } },
"pages": { "env": { "STORYBOOK_SCOPE": "pages" } },
"performance": { "env": { "STORYBOOK_SCOPE": "performance" } }
}
},
"storybook:static:test": {
"options": {
"commands": [
fix: fix storybook build cache not being used by tests in CI (#5451) TL;DR: - removed `--configuration={args.scope}` from `storybook:static:test` for the `storybook:static` part, as it was making `front-sb-test` jobs in CI not reuse the cache from the `front-sb-build` job and re-build storybook every time. - replaced it with a new `test` configuration which optimizes storybook build for tests and builds storybook 2x faster. ## Fix storybook:build cache usage in CI `storybook:static:test` executes two scripts in parallel: 1. `storybook:static`, which depends on `storybook:build` 1.a. it builds storybook first with `storybook:build`, the output directory is `storybook-static`. 1.b. then it launches an `http-server`, using what has been built in `storybook-static` 2. `storybook:test` to execute tests (needs the storybook http-server to be running) When passing `--configuration=pages` or `--configuration=modules` to `storybook:static` from step 1, those configurations are passed to the `storybook:build` script from step 1.a as well. But for Nx `storybook:build` and `storybook:build --configuration=pages` (or `modules`) are not the same command, therefore one does not reuse the cache of the other because they could output completely different things. As `front-sb-test` jobs are passing `--configuration={args.scope}` to `storybook:static`, the cache of the previously executed `storybook:build` (from `front-sb-build`) is not reused and therefore each job re-builds Storybook with its own scope, which increases CI time. ### Solution - Removed scope configurations from `storybook:static` and `storybook:build` scripts to avoid confusion. - `storybook:test` and `storybook:dev` can keep scope configurations as they can be useful and this doesn't impact storybook build cache in CI. ### Improve Storybook build time for testing Added the `test` configuration to `storybook:build` and `storybook:static` which makes Storybook build time 2x faster. It disables addons that slow down build time and are not used in tests.
2024-05-17 17:05:31 +03:00
"npx concurrently --kill-others --success=first -n SB,TEST 'nx storybook:static {projectName} --configuration=test --port={args.port}' 'npx wait-on tcp:{args.port} && nx storybook:test {projectName} --port={args.port} --configuration={args.scope}'"
],
"port": 6006
},
"configurations": {
"docs": { "scope": "ui-docs" },
"modules": { "scope": "modules" },
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 14:50:02 +03:00
"pages": { "scope": "pages" },
"performance": { "scope": "performance" }
}
},
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 14:50:02 +03:00
"storybook:performance:test": {},
"graphql:generate": {
"executor": "nx:run-commands",
"defaultConfiguration": "data",
"options": {
"cwd": "{projectRoot}",
"command": "dotenv cross-var graphql-codegen -- --config={args.config}"
},
"configurations": {
"data": {
"config": "codegen.cjs"
},
"metadata": {
"config": "codegen-metadata.cjs"
}
}
},
2024-04-30 19:21:08 +03:00
"chromatic": {
"configurations": {
"ci": {}
2024-04-30 19:21:08 +03:00
}
}
}
}