## Summary
Clean up and consolidate formatting configuration across the monorepo.
## Changes
### 1. Remove Redundant Configs
- ❌ Delete `packages/twenty-server/.prettierrc` (had invalid
`brakeBeforeElse` typo)
- ❌ Delete `packages/twenty-zapier/.prettierrc`
- ✅ Use root `.prettierrc` only (Prettier searches up directory tree
automatically)
### 2. Improve Root Prettier Config
- Change `endOfLine: 'auto'` → `'lf'` for consistent Unix line endings
across all OSes
### 3. Enhance VSCode Settings
- `files.eol: 'auto'` → `'\\n'` (consistent with Prettier)
- Add `files.insertFinalNewline: true` (explicit editor behavior)
- Add `files.trimTrailingWhitespace: true` (cleaner files)
### 4. Add `.gitattributes`
- Enforce LF line endings at Git level
- Prevents `core.autocrlf` from converting based on contributor's OS
- Mark patch files as binary (they have mixed line endings by design)
- Explicitly define binary file types
### 5. Fix Line Endings
- Convert 3 selectable-list state files from CRLF → LF
- These were the only source files with Windows line endings
## Why These Changes Matter
**Before:**
- 3 different Prettier configs (inconsistent, one had typo)
- Mixed CRLF/LF depending on contributor's OS
- No Git-level enforcement
**After:**
- Single source of truth for formatting
- All files use LF (Unix standard)
- Git enforces line endings regardless of OS
- Prettier warning about invalid option removed
## Result
- ✅ Single `.prettierrc` config
- ✅ Consistent LF line endings enforced by Git
- ✅ Better VSCode defaults
- ✅ No more CRLF files sneaking in from Windows contributors
We must separate the concept of hydratation which happens at the request
level (take the token and pass auth/user context), from the concept of
authorization which happens at the query/endpoint/mutation level.
Previously, hydratation exemption happened at the operation name level
which is not correct because the operation name is meaningless and
optional. Still this gave an impression of security by enforcing a
blacklist. So in this PR we introduce linting rule that aim to achieve a
similar behavior, now every api method has to have a guard. That way if
and endpoint is not protected by AuthUserGuard or AuthWorspaceGuard,
then it has to be stated explicitly next to its code.
---------
Co-authored-by: Charles Bochet <charles@twenty.com>
## Introduction
This PR enables functionality discussed in [Layout Date
Formatting](https://github.com/twentyhq/core-team-issues/issues/97).
### TLDR;
It enables greater control of date formatting at the object's field
level by upgrading all DATE and DATE_TIME fields' settings from:
```ts
{
displayAsRelativeDate: boolean
}
```
to:
```ts
type FieldDateDisplayFormat = 'full_date' | 'relative_date' | 'date' | 'time' | 'year' | 'custom'
{
displayFormat: FieldDateDisplayFormat
}
```
PR also includes an upgrade command that will update any existing DATE
and DATE_TIME fields to the new settings value
---------
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
Co-authored-by: Félix Malfait <felix@twenty.com>
Co-authored-by: Félix Malfait <felix.malfait@gmail.com>
### Description
This PR introduces a custom ESLint rule named
`inject-workspace-repository`. The purpose of this rule is to enforce
naming conventions for files and classes that use the
`@InjectWorkspaceRepository` decorator or include services ending with
`WorkspaceService` in their constructors.
### Rule Overview
The new ESLint rule checks for the following conditions:
1. **File Naming**:
- Only file ending with `.service.ts` or `.workspace-service.ts` are
checked.
- If a file contains a class using the `@InjectWorkspaceRepository`
decorator or a service ending with `WorkspaceService` in the
constructor, the file name must end with `.workspace-service.ts`.
2. **Class Naming**:
- Classes that use the `@InjectWorkspaceRepository` decorator or include
services ending with `WorkspaceService` in their constructors must have
names that end with `WorkspaceService`.
### How It Works
The rule inspects each TypeScript file to ensure that the naming
conventions are adhered to. It specifically looks for:
- Constructor parameters with the `@InjectWorkspaceRepository`
decorator.
- Constructor parameters with a type annotation ending with
`WorkspaceService`.
When such parameters are found, it checks the class name and the file
name to ensure they conform to the expected patterns.
### Example Code
#### Valid Cases
1. **Correct File and Class Name with Decorator**:
```typescript
// Filename: my.workspace-service.ts
class MyWorkspaceService {
constructor(@InjectWorkspaceRepository() private repository) {}
}
```
2. **Service Dependency**:
```typescript
// Filename: another.workspace-service.ts
class AnotherWorkspaceService {
constructor(private myWorkspaceService: MyWorkspaceService) {}
}
```
#### Invalid Cases
1. **Incorrect Class Name**:
```typescript
// Filename: my.workspace-service.ts
class MyService {
constructor(@InjectWorkspaceRepository() private repository) {}
}
// Error: Class name should end with 'WorkspaceService'.
```
2. **Incorrect File Name**:
```typescript
// Filename: my.service.ts
class MyWorkspaceService {
constructor(@InjectWorkspaceRepository() private repository) {}
}
// Error: File name should end with '.workspace-service.ts'.
```
3. **Incorrect File and Class Name**:
```typescript
// Filename: my.service.ts
class MyService {
constructor(@InjectWorkspaceRepository() private repository) {}
}
// Error: Class name should end with 'WorkspaceService'.
// Error: File name should end with '.workspace-service.ts'.
```
4. **Incorrect File Type**:
```typescript
// Filename: another.service.ts
class AnotherService {
constructor(private myWorkspaceService: MyWorkspaceService) {}
}
// Error: Class name should end with 'WorkspaceService'.
// Error: File name should end with '.workspace-service.ts'.
```
5. **Incorrect Class Name with Dependency**:
```typescript
// Filename: another.workspace-service.ts
class AnotherService {
constructor(private myWorkspaceService: MyWorkspaceService) {}
}
// Error: Class name should end with 'WorkspaceService'.
```
### First step
This rule is only a warning for now, and then we'll migrate all the code
that need to be migrated and move from `warn` to `error`.
Fix#6309
Co-authored-by: Charles Bochet <charles@twenty.com>
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.
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.
