TypeORM Entity in NESTJS - Cannot use import statement outside a module

In the TypeORM documentation, i found a specific section for Typescript.

This section says:

Install ts-node globally:

npm install -g ts-node

Add typeorm command under scripts section in package.json

"scripts" {
    ...
    "typeorm": "ts-node -r tsconfig-paths/register ./node_modules/typeorm/cli.js"    
}

Then you may run the command like this:

npm run typeorm migration:run

If you need to pass parameter with dash to npm script, you will need to add them after --. For example, if you need to generate, the command is like this:

npm run typeorm migration:generate -- -n migrationNameHere

This works with my file config:

{
    "type": "postgres",
    "host": "yourhost",
    "port": 5423,
    "username": "username",
    "password": "password",
    "database": "your_db",
    "synchronize": true,
    "entities": [
        "src/modules/**/*.entity.{ts,js}"
    ],
    "migrations": [
        "src/migrations/**/*.{ts,js}"
    ],
    "cli": {
        "entitiesDir": "src/modules",
        "migrationsDir": "src/migrations"
    }
}

Then you can run the generate command.

As Jay McDoniel explained in his answer, the problem seems to be the pattern matching of entity files in ormconfig.json file: Probably a typescript file (module) is imported from a javascript file (presumably a previously transpiled typescript file).

It should be sufficient to remove an existing ts glob pattern in the ormconfig.json, so that TypeORM will only load javascript files. The path to the entity files should be relative to the working directory where node is executed.

   "entities"   : [
      "dist/entity/**/*.js"
   ],
   "migrations" : [
      "dist/migration/**/*.js"
   ],
   "subscribers": [
      "dist/subscriber/**/*.js"
   ],

Defining the entities property in ormconfig.json as mentioned in the official documentation resolved this issue for me.

// This is your ormconfig.json file

...
"entities": ["dist/**/*.entity{.ts,.js}"]
...

I changed in tsconfig.json file next:

"module": "es6"

To:

"module": "commonjs",

It helps me

Also check out your imports in the entities. Don't import { SomeClassFromTypeorm } from 'typeorm/browser'; since this can lead to the same error.

It happened to me after my IDE automatically imported the wrong package. Delete '/browser' from the import.

This is how I've manage to fix it. With a single configuration file I can run the migrations on application boostrap or using TypeOrm's CLI.

src/config/ormconfig.ts

import parseBoolean from '@eturino/ts-parse-boolean';
import { TypeOrmModuleOptions } from '@nestjs/typeorm';
import * as dotenv from 'dotenv';
import { join } from 'path';

dotenv.config();

export = [
  {
    //name: 'default',
    type: 'mssql',
    host: process.env.DEFAULT_DB_HOST,
    username: process.env.DEFAULT_DB_USERNAME,
    password: process.env.DEFAULT_DB_PASSWORD,
    database: process.env.DEFAULT_DB_NAME,
    options: {
      instanceName: process.env.DEFAULT_DB_INSTANCE,
      enableArithAbort: false,
    },
    logging: parseBoolean(process.env.DEFAULT_DB_LOGGING),
    dropSchema: false,
    synchronize: false,
    migrationsRun: parseBoolean(process.env.DEFAULT_DB_RUN_MIGRATIONS),
    migrations: [join(__dirname, '..', 'model/migration/*.{ts,js}')],
    cli: {
      migrationsDir: 'src/model/migration',
    },
    entities: [
      join(__dirname, '..', 'model/entity/default/**/*.entity.{ts,js}'),
    ],
  } as TypeOrmModuleOptions,
  {
    name: 'other',
    type: 'mssql',
    host: process.env.OTHER_DB_HOST,
    username: process.env.OTHER_DB_USERNAME,
    password: process.env.OTHER_DB_PASSWORD,
    database: process.env.OTHER_DB_NAME,
    options: {
      instanceName: process.env.OTHER_DB_INSTANCE,
      enableArithAbort: false,
    },
    logging: parseBoolean(process.env.OTHER_DB_LOGGING),
    dropSchema: false,
    synchronize: false,
    migrationsRun: false,
    entities: [],
  } as TypeOrmModuleOptions,
];

src/app.module.ts

import configuration from '@config/configuration';
import validationSchema from '@config/validation';
import { Module } from '@nestjs/common';
import { ConfigModule } from '@nestjs/config';
import { TypeOrmModule } from '@nestjs/typeorm';
import { LoggerService } from '@shared/logger/logger.service';
import { UsersModule } from '@user/user.module';
import { AppController } from './app.controller';
import ormconfig = require('./config/ormconfig'); //path mapping doesn't work here

@Module({
  imports: [
    ConfigModule.forRoot({
      cache: true,
      isGlobal: true,
      validationSchema: validationSchema,
      load: [configuration],
    }),
    TypeOrmModule.forRoot(ormconfig[0]), //default
    TypeOrmModule.forRoot(ormconfig[1]), //other db
    LoggerService,
    UsersModule,
  ],
  controllers: [AppController],
})
export class AppModule {}

package.json

  "scripts": {
    ...
    "typeorm": "ts-node -r tsconfig-paths/register ./node_modules/typeorm/cli.js --config ./src/config/ormconfig.ts",
    "typeorm:migration:generate": "npm run typeorm -- migration:generate -n",
    "typeorm:migration:run": "npm run typeorm -- migration:run"
  },

Project structure

src/
├── app.controller.ts
├── app.module.ts
├── config
│   ├── configuration.ts
│   ├── ormconfig.ts
│   └── validation.ts
├── main.ts
├── model
│   ├── entity
│   ├── migration
│   └── repository
├── route
│   └── user
└── shared
    └── logger

Surprised by these almost kinda hacky solutions, particularly of the accepted one...

You should never import anything from a dist folder inside your ts source code!

If the answered assumption is true, and you do this:

entities: ['src/**/*.entity.{ts,js}']

then, why don't you rather DO THIS:

import { Answer } from './entities/answer/answer.entity';

entities: [Answer]

This way you would you use your ts code (correctly) and the builded js code would get provided to the TypeOrmModule in runtime.

I was using Node.js with Typescript and TypeORM when I faced this issue. Configuring in ormconfig.json file worked for me.

entities: ['dist/**/*.entity.js']

My full code of ormconfig.json file:

{
  "type": "mysql",
  "host": "localhost",
  "port": 3306,
  "username": "xxxxxxxx",
  "password": "xxxxxxxx",
  "database": "typescript_orm",
  "synchronize": true,
  "logging": false,
  "migrationTableName": "migrations",
  "entities": [
    "dist/**/*.entity.js"
  ],
  "migrations": [
    "src/migration/**/*.{ts, js}"
  ],
  "suscribers": [
    "src/suscriber/**/*.{ts, js}"
  ],
  "cli": {
    "entitiesDir": "src/model",
    "migrationDir": "src/migration",
    "suscribersDir": "src/suscriber"
  }
}

check your TypeOrmModule's entities

TypeOrmModule.forRoot({
  type: 'postgres',
  host: 'localhost',
  port: 5432,
  username: 'postgres',
  password: '#GoHomeGota',
  database: 'quiz',
  **entities: ["dist/**/*.entity{.ts,.js}"],**
  synchronize: true,
}),

In line with other people's comments - it does in fact seem silly to have to depend on generated code for this to work. I do not take credit for this solution as it's someone else's repository, but it does in fact allow full Typescript only migrations. It relies on the .env file Typeorm values instead of ormconfig.json although I'm sure it could be translated. I found it instrumental in helping me remove the dependency on .js files.

Here is the repo: https://github.com/mthomps4/next-now-test/tree/next-typeorm-example

Explanation as to how it's working:

Aside from your usual .env or ormconfig.json file with the proper localhost db connection in it, you also need to specify the following properly in ormconfig.json or .env file

TYPEORM_ENTITIES="entities/*.ts"
TYPEORM_MIGRATIONS="migrations/*.ts"
TYPEORM_ENTITIES_DIR="entities"
TYPEORM_MIGRATIONS_DIR="migrations"

Notice the entities and migrations globs only have *.ts. The other very important piece is how your npm scripts are setup to run with ts-node.

You need an extended tsconfig that has the following in it somewhere:

{
  "extends": "./tsconfig.json",
  "compilerOptions": {
    "module": "commonjs"
  }
}

This is what allows ts-node to "pick up" the .ts files properly while generating a migration.

This npm script (the DOTENV part is only if using .env files instead of ormconfig.json) specifies to use that tsconfig.json

 "local": "DOTENV_CONFIG_PATH=./.env ts-node -P ./tsconfig.yarn.json -r dotenv/config"

Which is leveraged as a "pre-cursor" script to this:

"typeorm:local": "yarn local ./node_modules/typeorm/cli.js"

I'm not 100% sure all of that is necessary (you may could do it all inline) but it works for me. Basically this says "invoke the typrorm cli in the context of ts-node with a specific .env file and a specific tsconfig." You may be able to skip those configurations in some cases.

Lastly, this script now works:

"g:migration": "yarn typeorm:local migration:generate -n"

So by running:

npm run g:migration -- User

You will get your automatically generated migration file based on your current changed entities!

So 3 nested npm scripts later, we have a very specific way to run the "generate" migration conmmand with all the proper configuration to use only TS files. Yay - no wonder some people still rail against typescript but thankfully this does work and the example repo above has it all preconfigured if you want to try it out to see how it "just works".

The alternative I found for this is having two orm config files namely orm-config.ts and cli-orm-config.ts (You can name them whatever)

//content of cli-orm-config.ts

import { DataSource, DataSourceOptions } from "typeorm"
import 'dotenv/config'

export const cliOrmConfig: DataSourceOptions = {
    type: 'postgres',
    host: process.env.DATABASE_HOST,
    port: (process.env.PG_DATABASE_PORT as any) as number,
    username: process.env.PG_DATABASE_USER,
    password: process.env.PG_DATABASE_PASSWORD,
    database: process.env.DATABASE_NAME,
    entities: ["src/**/*/*.entity{.ts,.js}"],
    migrations: ["src/**/*/*-Migration{.ts,.js}"]
}

const datasource = new DataSource(cliOrmConfig)

export default  datasource

//content of orm-config.ts, this is the one I use in nest TypeOrmModule.forRoot(ormConfig)

import { DataSource, DataSourceOptions } from 'typeorm';
import 'dotenv/config'


export const ormConfig: DataSourceOptions = {
    type: 'postgres',
    host: process.env.DATABASE_HOST,
    port: (process.env.PG_DATABASE_PORT as any) as number,
    username: process.env.PG_DATABASE_USER,
    password: process.env.PG_DATABASE_PASSWORD,
    database: process.env.DATABASE_NAME,
    entities: ["dist/src/**/*/*.entity{.ts,.js}"]
}

const datasource = new DataSource(ormConfig)

export default  datasource

// My package.json relevant scripts section

"typeorm": "ts-node ./node_modules/typeorm/cli -d ./src/db/cli-orm-config.ts",
"nest:migration:generate": "npm run typeorm migration:generate ./src/db/migrations/Migration",
"nest:migration:run": "npm run typeorm migration:run"

I think as far as TypeOrm is concerned, the migration, cli parts should be teared apart from models loading and other stuffs; hence the seperation of the orm configs file for both.

Hope it helps somebody

I Upgraded NestJs to 9.2.0 and typeorm to 0.3.10 And i got a probleme when runing a new migration But i Found out the solution and that works for me:

in the previous Version (nest 7 typeorm 0.2) i used this command :

npx ts-node ./node_modules/.bin/typeorm migration:generate -n MigrationName -d src/migrations 

and after updating i used this command and it workd for me:

npx ts-node ./node_modules/.bin/typeorm migration:generate src/migration/MigrationName -d ormconfig.js

when generate migration we need to set the path of the new migrationFile migration:generate

-d means directory of migration => -d src/migration in typeorm 0.2

-d means dataSource (config) => -d ormconfig in typeorm 0.3

Actually, typeorm was designed to work with javascript by default.

To run the migrations with typescript, you must tell typeorm to do it.

Just put in your package.json, in the scripts part this line below:

"typeorm": "ts-node-dev ./node_modules/typeorm/cli.js"

and then, try to migrate again:

yarn typeorm migration:run

I think a better solution, than the accepted one, is to create a alias in your shell of choice, that uses ts-node inside node_modules.

Note: I'm doing this in bash, with OhMyZsh, so your configuration might be totally different.

1: Open shell configuration

Open shell configuration1

nano ~/.zshrc

2: Find the place where other aliases are defined and add a new alias

alias typeorm="ts-node ./node_modules/typeorm/cli.js"

3: Close and save

Press CTRL + X to request nano to exit and press Y to confirm to save the configuration.

4: Apply the new configuration

. ~/.zshrc

5: Close terminal and open it again

You can now go to your project root and type "typeorm" which will use ts-node in conjunction with the typeorm-cli from your node_modules.

I ran into this error trying to run typeorm migration:generate from a project created with the TypeORM starter kit (npx typeorm init). The issue came down to this bit that it inserted into package.json:

   "scripts": {
      "typeorm": "typeorm-ts-node-commonjs"
   }

Change that to:

   "scripts": {
      "typeorm": "typeorm-ts-node-esm"
   }

And you should be good to go:

npm run -- typeorm migration:generate --dataSource path/to/data-source.ts NameOfMigration

You need to have a something.module.ts for every section of your app. It works like Angular. This is setup with GraphQL resolvers and service. REST is a bit different with a controller. Each module will probably have an entity and if GraphQL, projects.schema.graphql.

projects.module.ts

import { Module } from '@nestjs/common';
import { TypeOrmModule } from '@nestjs/typeorm';
import { ProjectsService } from './projects.service';
import { Projects } from './projects.entity';

import { ProjectsResolvers } from './projects.resolvers';

@Module({
  imports: [
    TypeOrmModule.forFeature([Projects])],
  providers: [
    ProjectsService,
    ProjectsResolvers
  ],

})

export class ProjectsModule {}

This worked for me - no changes needed to your ormconfig.js. Run from your root directory where the node_modules are:

ts-node ./node_modules/typeorm/cli.js  migration:generate -n <MirgrationName> -c <ConnectionType>

Example:

ts-node ./node_modules/typeorm/cli.js  migration:create -n AuthorHasMultipleBooks -c development 

Configuration to support migrations:

// FILE: src/config/ormconfig.ts

const connectionOptions: ConnectionOptions = {
  
  // Other configs here

  // My ormconfig isn't in root folder
  entities: [`${__dirname}/../**/*.entity.{ts,js}`],
  synchronize: false,
  dropSchema: false,
  migrationsRun: false,
  migrations: [getMigrationDirectory()],
  cli: {
    migrationsDir: 'src/migrations',
  }
}

function getMigrationDirectory() {
    const directory = process.env.NODE_ENV === 'migration' ? 'src' : `${__dirname}`;
    return `${directory}/migrations/**/*{.ts,.js}`;
}

export = connectionOptions;

// FILE package.json

{
  // Other configs here

  "scripts": {
    "typeorm": "NODE_ENV=migration ts-node -r tsconfig-paths/register ./node_modules/typeorm/cli.js --config src/config/database.ts",
    "typeorm:migrate": "npm run typeorm migration:generate -- -n",
    "typeorm:run": "npm run typeorm migration:run",
    "typeorm:revert": "npm run typeorm migration:revert"
  }
}

I have encountered the same problem. The only difference is that my project uses .env file instead of ormconfig.json

This is what my .env file configuration looks like.

TYPEORM_ENTITIES = src/modules/*.entity.ts
TYPEORM_MIGRATIONS = src/migrations/*.entity.ts
TYPEORM_MIGRATIONS_RUN = src/migrations
TYPEORM_ENTITIES_DIR = src/modules
TYPEORM_MIGRATIONS_DIR = src/migrations

And run by using command

nest start

The problem appears to be that TypeORM does not accept entities in the form of typescript files.

There are two approaches that can be used to solve this problem.

1. Use node-ts instead of nest start solved the problem without modifying the path of the entities file. From my understanding, node-ts will process the typescript file in the src folder without issue.

2. Change the entity and migration file paths to point to the compiled js file in the dist folder instead.

    TYPEORM_ENTITIES = dist/modules/*.entity.js
    TYPEORM_MIGRATIONS = dist/migrations/*.entity.js
    TYPEORM_MIGRATIONS_RUN = dist/migrations
    TYPEORM_ENTITIES_DIR = dist/modules
    TYPEORM_MIGRATIONS_DIR = dist/migrations
   

   with this approach, I can use nest start without any problem.

I used this solution only for production. for development I change "../src/entity/**/*.ts" to "src/entity/**/*.ts" and then run this command: "nodemon --exec ts-node ./src/index.ts" and it works –

I solved the problem!

1. Create pm2.config.js file in root with below codes:

    module.exports = {
      apps: [
        {
          name: "app",
          script: "./build/index.js",
        },
      ],
    };
   

2. Change entity path in ormconfig.js

   {
      "type": "postgres",
      "host": "localhost",
      "port": 5432,
      "username": "postgres",
      "password": "password",
      "database": "db_name",
      "synchronize": false,
      "logging": true,
      "entities": [
         "../src/entity/**/*.ts",  ===>>> this line is important
         "./build/entity/**/*.js"
      ],
      "migrations": [
         "../src/migration/**/*.ts",===>>> this line is important
         "./build/migration/**/*.js"
      ],
      "subscribers": [
         "../src/subscriber/**/*.ts",===>>> this line is important
         "./build/subscriber/**/*.js"
      ],
      "cli": {
         "entitiesDir": "src/entity",
         "migrationsDir": "src/migration",
         "subscribersDir": "src/subscriber"
      }
   }
   

3. tsconfig.json with below code:

   {
      "compilerOptions": {
         "lib": [
            "es5",
            "es6"
         ],
         "target": "es5",
         "module": "commonjs",
         "moduleResolution": "node",
         "outDir": "./build",
         "emitDecoratorMetadata": true,
         "experimentalDecorators": true,
         "sourceMap": true,
         "esModuleInterop": true
      }
   }
   

4. Run below command for production:

   tsc  =>> This command generate "build" folder
   

5. Run below command for run node app in pm2:

   tsc && pm2 start pm2.config.js
   

Now after 2 days with this solution my app with node express & typeorm is worked! Also my app are working on linux & nginx with pm2.

The accepted answer here (https://stackoverflow.com/a/59607836/2040160) was help me generate and run the migrations, but not to run the NestJS project. I got the same error as the author when I npm run start:dev.

What worked for me, is to just generate the migrations file in vanilla JavaScript. My ormconfig,json file:

{ 
  "type": "cockroachdb",
  "host": "localhost",
  "port": 26257,
  "username": "root",
  "password": "",
  "database": "test",
  "entities": ["dist/**/*.entity{.ts,.js}"],
  "migrations": ["migration/*.js"],
  "synchronize": false,
  "cli": {
    "migrationsDir": "migration"
  }
}

The script in package.json:

"typeorm": "node --require ts-node/register ./node_modules/typeorm/cli.js"

And the command I use to generate the migrations:

npm run typeorm migration:generate -- -o -n init

The -o flag will output the migrations in vanilla JavaScript.

If you are still stuck with this issue, here is what worked for me //my typeorm.config.ts

import { DataSource, DataSourceOptions } from 'typeorm';
import { ConfigService } from '@nestjs/config';
import { config } from 'dotenv';
import * as path from 'path';
import { User } from '../users/users.entity';
import { FileStorage } from '../storage/storage.entity';

// Load environment variables
config({ path: `.env.${process.env.ENV}` });

const configService = new ConfigService();

// Minimal data source options
export const dataSourceOptionsMinimal = {
  type: 'postgres',
  host: configService.getOrThrow('DB_HOST'),
  port: parseInt(configService.getOrThrow('DB_PORT'), 10),
  username: configService.getOrThrow('DB_USERNAME'),
  password: configService.getOrThrow('DB_PASSWORD'),
  database: configService.getOrThrow('DB_DATABASE'),
};

// Full data source options
export const dataSourceOptions: DataSourceOptions = {
  ...dataSourceOptionsMinimal,
  type: 'postgres',
  entities: [User, FileStorage],
  migrations: [path.join(__dirname, 'migrations/**/*.{ts,js}')],
  migrationsTableName: 'migrations',
};

export default new DataSource(dataSourceOptions);

If you are writing in typescript and use tsc to create a dist folder with translated js files in it, then you probably have my issue and it will get fixed here.

As it is mentioned here in the docs if you use nodemon server.js, then you will hit the entities from js perspective and it will not recognize import as it is ts and es6 related. However if you want to import entities from ts files, you should run ts-node server.ts!

Personally I believe the former node server.js is a safer one to do as it is closer to the real case application.

!!! HOWEVER !!! Be very careful as you have to delete the dist folder and rebuild it if you change an entity's name, otherwise it will throw an error or work unexpectedly. The error happens because the tsc will try to translate the changed and created ts files and leave the deleted files so it can run faster!

I hope it helped as it will definitely help me in the future as I am almost certain I will forget about it again!

For me, changing module in my tsconfig.ts from

"module": "esnext"

To:

"module": "commonjs",

Did the job.

In my scenario, the import statement problem persisted despite attempting various troubleshooting steps. Initially, my Node.js environment was set to version 20. However, after exhausting multiple solutions without success, I switched to Node.js version 18 and this issue was resolved.

Ensure that the directory path in your TypeORM configuration is accurate by prepending a "/" with src.

The difference between using /src and src in a TypeORM configuration (or any file path configuration) is as follows:

/src: An absolute path that starts from the root of the filesystem. This tells the system to look for the src directory starting from the root directory of your system. This is generally not what you want in most project setups.

src: A relative path that starts from the current working directory.

This could happen if your project is set up in such a way that the working directory is not the root of your project but some other directory. Using /src ensures that the path is correctly resolved regardless of where the command is run.

Small tip for NestJs, In development mode, you can keep the .env variables with .ts for entities.

Use ts-node to run your program rather than nest start

You can simply replace your dev command in package.json from

"dev": "nest start --watch",

to

"dev": "NODE_ENV=test 'ts-node' src/main.ts",

Ensure that ts-node is globally installed.