# TypeORM-TypeScript ESLint Plugin

An ESLint plugin to catch mistakes if the TypeORM column types and TypeScript types aren't consistent.

![Example of an error message](./docs/images/error-message.png)

## Installation

Install the package for the plugin:

```sh
npm install -D eslint-plugin-typeorm-typescript
```

### Flat configuration

To enable all rules, add the recommended configuration for `eslint-plugin-typeorm-typescript` to `eslint.config.mjs`:

```js
import eslint from '@eslint/js';
import tseslint from 'typescript-eslint';
import typeormTypescriptRecommended from 'eslint-plugin-typeorm-typescript/recommended';

export default tseslint.config(
    eslint.configs.recommended,
    ...tseslint.configs.recommended,
    typeormTypescriptRecommended,
);
```

If you want to change the options, enable the plugin and the rules manually:

```js
import eslint from '@eslint/js';
import tseslint from 'typescript-eslint';
import typeormTypescriptPlugin from 'eslint-plugin-typeorm-typescript';

export default tseslint.config(eslint.configs.recommended, ...tseslint.configs.recommended, {
    plugins: { 'typeorm-typescript': typeormTypescriptPlugin },
    rules: {
        'typeorm-typescript/enforce-column-types': 'error',
        'typeorm-typescript/enforce-relation-types': 'warn',
        'typeorm-typescript/enforce-consistent-nullability': [
            'error',
            { specifyNullable: 'always' },
        ],
        'typeorm-typescript/enforce-column-name': [
            'error',
            { prefer: 'snake_case', specifyName: 'non-default' },
        ],
    },
});
```

For more information, see an example of the [recommended configuration](./examples/recommended/) or the [customized configuration](./examples/customized/).

### Legacy configuration

If you are still on legacy ESLint, update `.eslintrc.json` with the plugin to the `plugins` key, and add it to the `rules`:

```json
{
    "plugins": ["typeorm-typescript"],
    "rules": {
        "typeorm-typescript/enforce-column-types": "error",
        "typeorm-typescript/enforce-relation-types": "error",
        "typeorm-typescript/enforce-consistent-nullability": "error"
    }
}
```

For more information, see an example of the [legacy configuration](./examples/legacy/).

## Rules

TypeORM has no way to statically analyze if there is an inconsistency in the annotated TypeScript types.
With the addition, that there are some confusing rules around nullability (relations are nullable by default,
but columns aren't), it makes it easy to make mistakes. These ESLint rules will spot these issues, and suggest fixes.

### typeorm-typescript/enforce-column-types

TypeORM data types and TypeScript types should be consistent. It checks the primitive types (e.g. `VARCHAR` -> `string`)
and driver-specific types. By most drivers, `bigint` and `decimal` are parsed as string, except in SQLite (set the `driver`
option, if you use SQLite). This rule checks the nullability too: by default columns are non-nullable, but if the `nullable: true`
option is set, it should be unioned with `null` in the TypeScript types as well.

It also handle primary columns (`number` by default), create and update columns (`date` by default) and delete columns
(`date` and nullable by default).

#### Configuration

```json
{
    "rules": {
        "typeorm-typescript/enforce-column-types": "error",
        // If you are using SQLite, set the driver
        "typeorm-typescript/enforce-relation-types": ["error", { "driver": "sqlite" }]
    }
}
```

#### Examples

Examples of **incorrect code** for this rule:

```ts
class Entity {
    // Should be string
    @Column({ type: 'varchar' })
    name: number;

    // Should be string | null
    @Column({ type: 'varchar', nullable: true })
    name: string;

    // Should be Date | null
    @DeleteDateColumn()
    deletedAt: Date;
}
```

Examples of **correct code** for this rule:

```ts
class Entity {
    // TypeORM data type and TypeScript type are consistent
    @Column({ type: 'varchar' })
    name: string;

    // Nullability is correct
    @Column({ type: 'varchar', nullable: true })
    name: string | null;
}
```

### typeorm-typescript/enforce-relation-types

TypeORM relation types and TypeScript types should be consistent. Because the names are similar, it can be easily confused
that `ManyToOne` should be singular, and `OneToMany` an array. Additionally, `OneToOne` and `ManyToOne` are nullable,
which is an easy mistake to make.

Another common issue with TypeORM is not specifying a relation when querying. One way to avoid this is to check for `undefined`
when accessing any relation. Set `specifyUndefined` to always, so all relations have to be marked as `undefined`, forcing the
null-check every time.

This rule also supports the [ESM Relation wrapper](https://typeorm.io/#relations-in-esm-projects). If you are using ES Modules
and want to avoid circular dependency issues, you can set `specifyRelation` to always to make sure that relations are always
wrapped with `Relation<...>`.

#### Configuration

```json
{
    "rules": {
        "typeorm-typescript/enforce-relation-types": "error",
        // If you want to force null-checking before accessing a relation
        "typeorm-typescript/enforce-relation-types": ["error", { "specifyUndefined": "always" }],
        // If you want to force setting Relation<...> everywhere
        "typeorm-typescript/enforce-relation-types": ["error", { "specifyRelation": "always" }]
    }
}
```

#### Examples

Examples of **incorrect code** for this rule:

```ts
class Entity {
    // Should be Other | null
    @OneToOne(() => Other)
    @JoinColumn()
    other: Other;

    // Should be Other[]
    @OneToMany(() => Other, (other) => other.entity)
    other: Other;

    // Should be Other | null
    @ManyToOne(() => Other)
    other: Other;

    // Should be Other[]
    @ManyToMany(() => Other)
    @JoinTable()
    other: Other;

    // Should be Other | null
    @OneToOne(() => Other)
    @JoinColumn()
    other: Another | null;

    // Must add undefined with specifyUndefined: always
    @ManyToMany(() => Other)
    @JoinTable()
    other: Other;
}
```

Examples of **correct code** for this rule:

```ts
class Entity {
    // Join is correctly nullable...
    @OneToOne(() => Other)
    @JoinColumn()
    other: Other | null;

    // ...or explicitly marked nullable: false
    @OneToOne(() => Other, { nullable: false })
    @JoinColumn()
    other: Other;

    // *ToMany rules are an array
    @OneToMany(() => Other, (other) => other.entity)
    others: Other[];

    // Undefined added with specifyUndefined: always
    @ManyToMany(() => Other)
    @JoinTable()
    other: Other | undefined;
}
```

### typeorm-typescript/enforce-consistent-nullability

The main source of confusion with TypeORM decorators is that the `nullable` flag is different between columns and relations.
It is further complicated by being able to set the default value in some places and omit from others. Enable this rule to make sure
that either only the non-default value is set (no parameters or `non-default`) or the nullable must be specified every time (`always`).

#### Configuration

```jsonc
{
    "rules": {
        // If you want to report an error for unnecessary nullables
        "typeorm-typescript/enforce-consistent-nullability": "error", // or
        "typeorm-typescript/enforce-consistent-nullability": [
            "error",
            { "specifyNullable": "non-default" },
        ],
        // If you want to force setting nullable everywhere to avoid confusion
        "typeorm-typescript/enforce-consistent-nullability": [
            "error",
            { "specifyNullable": "always" },
        ],
    },
}
```

#### Examples

Examples of **incorrect code** for this rule:

With `{ "specifyNullable": "non-default" }`:

```ts
class Entity {
    // Columns are non-nullable by default, remove it
    @Column({ type: 'varchar', nullable: false })
    name: number;

    // Relations are nullable by default, remove it
    @OneToOne(() => Other, { nullable: true })
    @JoinColumn()
    other: Other | null;
}
```

With `{ "specifyNullable": "always" }`:

```ts
class Entity {
    // Mark this to nullable false to make it clear
    @Column({ type: 'varchar' })
    name: number;

    // Mark this to nullable true to make it clear
    @OneToOne(() => Other)
    @JoinColumn()
    other: Other | null;
}
```

Examples of **correct code** for this rule:

With `{ "specifyNullable": "non-default" }`:

```ts
class Entity {
    // Nullability only defined when it is different than default
    @Column({ type: 'varchar', nullable: true })
    middleName: number | null;

    @Column({ type: 'varchar' })
    name: number;

    @OneToOne(() => Other)
    @JoinColumn()
    other: Other | null;
}
```

With `{ "specifyNullable": "always" }`:

```ts
class Entity {
    // Nullable is set everywhere, no default behaviour is implied
    @Column({ type: 'varchar', nullable: true })
    middleName: number | null;

    @Column({ type: 'varchar', nullable: false })
    name: number;

    @OneToOne(() => Other, { nullable: true })
    @JoinColumn()
    other: Other | null;
}
```

### typeorm-typescript/enforce-column-name

TypeORM column decorators can derive a database column name from the property name, but teams often want to enforce a specific naming style or require explicit `name` declarations in non-default cases. This rule checks TypeORM column decorators whose names end with `Column` and support the `name` option.

Use `prefer` to choose the database naming style:

- `snake_case` (default)
- `lowerCamelCase`

Use `specifyName` to control when `name` must be written explicitly:

- `non-default` (default): only require `name` when the default derived name would not match the preferred convention; redundant default names are reported
- `always`: always require `name`

#### Configuration

```json
{
    "rules": {
        "typeorm-typescript/enforce-column-name": [
            "error",
            {
                "prefer": "snake_case",
                "specifyName": "non-default"
            }
        ]
    }
}
```

#### Examples

Examples of **incorrect code** for this rule:

```ts
class Entity {
    // Name does not match snake_case convention
    @Column({ name: 'createdAt' })
    createdAt: Date;

    // Missing explicit name for non-snake_case property
    @Column()
    userID: string;
}
```

Examples of **correct code** for this rule:

```ts
class Entity {
    // Property already matches convention, no name needed
    @Column()
    id: number;

    // Explicit name converts to snake_case
    @Column({ name: 'user_id' })
    userID: string;

    // Explicit name converts to snake_case
    @Column({ name: 'created_at' })
    createdAt: Date;
}
```