
Security News
Deno 2.4 Brings Back deno bundle, Improves Dependency Management and Observability
Deno 2.4 brings back bundling, improves dependency updates and telemetry, and makes the runtime more practical for real-world JavaScript projects.
eslint-plugin-typeorm-typescript
Advanced tools
An ESLint plugin to catch mistakes if the TypeORM column types and TypeScript types aren't consistent.
An ESLint plugin to catch mistakes if the TypeORM column types and TypeScript types aren't consistent.
Install the package for the plugin:
npm install -D eslint-plugin-typeorm-typescript
To enable all rules, add the recommended configuration for eslint-plugin-typeorm-typescript
to eslint.config.mjs
:
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:
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" }]
}
}
);
For more information, see an example of the recommended configuration.
If you are still on legacy ESLint, update .eslintrc.json
with the plugin to the plugins
key, and add it to the rules
:
{
"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.
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 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).
{
"rules": {
"typeorm-typescript/enforce-column-types": "error",
// If you are using SQLite, set the driver
"typeorm-typescript/enforce-relation-types": ["error", { "driver": "sqlite" }],
}
}
Examples of incorrect code for this rule:
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:
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 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.
This rule also supports the ESM Relation wrapper. 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<...>
.
{
"rules": {
"typeorm-typescript/enforce-relation-types": "error",
// If you want to force setting Relation<...> everywhere
"typeorm-typescript/enforce-relation-types": ["error", { "specifyRelation": "always" }],
}
}
Examples of incorrect code for this rule:
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;
}
Examples of correct code for this rule:
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[];
}
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
).
{
"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 of incorrect code for this rule:
With { "specifyNullable": "non-default" }
:
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" }
:
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" }
:
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" }
:
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;
}
[0.5.0] - 2024-12-06
customized
example (with tests) to display the customization optionsbigint
and decimal
are now parsed correctly according to the driver (#5)
driver
for enforce-column-types
: can be 'postgres', 'mysql' or 'sqlite'FAQs
An ESLint plugin to catch mistakes if the TypeORM column types and TypeScript types aren't consistent.
The npm package eslint-plugin-typeorm-typescript receives a total of 7,374 weekly downloads. As such, eslint-plugin-typeorm-typescript popularity was classified as popular.
We found that eslint-plugin-typeorm-typescript demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 0 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Deno 2.4 brings back bundling, improves dependency updates and telemetry, and makes the runtime more practical for real-world JavaScript projects.
Security News
CVEForecast.org uses machine learning to project a record-breaking surge in vulnerability disclosures in 2025.
Security News
Browserslist-rs now uses static data to reduce binary size by over 1MB, improving memory use and performance for Rust-based frontend tools.