typeorm: Entities no longer registered after Hot Reloading

I found a workaround that may be worth trying (source): In addition to listing the entities manually

createConnection({
  ...
  entities: [
    UserEntity,    //  <--- here
  ],
});

i then had to lookup the repository by name/string

connection.getRepository<UserEntity>("UserEntity")

instead of by type/class

connection.getRepository(UserEntity)

to avoid the problem that HMR seems to create different compiled versions of UserEntity as described here:

Because TypeORM connection manager is not aware of entity class reloads … … Next.js will load and create a class reference for it - let’s call it “User v1”. … Now, once you edit that class file, Next.js will perform a hot reload, and there are now two different class references living inside runtime memory. One is the original “User v1” and another one is the freshly recompiled “User v2”. Your route code is now using the “User v2” class reference, but the connection still has “User v1” in its list of known entities. When you try to e.g. call getRepository(User) in your code, you will not > be passing the same class reference as what TypeORM “knows”

Don’t know if it’s the same problem but I also encountered this and the problem in my case was that I had an ormconfig.js file but also a .env file with:

TYPEORM_CONNECTION = mysql
TYPEORM_HOST = localhost
TYPEORM_USERNAME = test
TYPEORM_PASSWORD = test
TYPEORM_DATABASE = test
TYPEORM_PORT = 3306

And because of this, TypeORM was loading the configuration from .env and completely ignored .ormconfig.js. I solved this by renaming my env vars.

Thanks for looking into it @imnotjames !

If you mean by “passing them directly” to add the classes to the entities: [class, class, ...] array- yes I tried that, and it also resulted in an error.

I have solution @seandearnaley we can solve this problem with replacing code like this

Before

protected findMetadata(target: Function|EntitySchema<any>|string): EntityMetadata|undefined {
        return this.entityMetadatas.find(metadata => {
            if (metadata.target === target)
                return true;
            if (target instanceof EntitySchema) {
                return metadata.name === target.options.name;
            }
            if (typeof target === "string") {
                if (target.indexOf(".") !== -1) {
                    return metadata.tablePath === target;
                } else {
                    return metadata.name === target || metadata.tableName === target;
                }
            }

            return false;
        });
    }

After

protected findMetadata(target: Function|EntitySchema<any>|string): EntityMetadata|undefined {
        return this.entityMetadatas.find(metadata => {
            if (Object.getPrototypeOf(metadata.target) === Object.getPrototypeOf(target)&&metadata.target.name===target.name)
                // First Check if target is made from same entity constructor as metadata target have. Then check if target name is same as metadata target name
                return true;
            if (target instanceof EntitySchema) {// I don't know if this condition is necessary
                return metadata.name === target.options.name;
            }
            if (typeof target === "string") {// I don't know if this condition is necessary
                if (target.indexOf(".") !== -1) {
                    return metadata.tablePath === target;
                } else {
                    return metadata.name === target || metadata.tableName === target;
                }
            }

            return false;
        });
    }

Object.getPrototypeOf(metadata.target) === Object.getPrototypeOf(target) will satisfy the problem requirement

1. check if metadata.target is same as target
2. check if target is not only same named function but also created by entity constructor (resolve false positivity)

I can confirm this still happens, happened with me in a serverless environment. I rolled back to v0.2.22 and it got fixed.

Figured I would throw in this completely useless statement: Its Aug 2022, this issue has been in my life >1 year. It’s clearly difficult to address.

Thank you TypeORM team for everything you.

I’m also using Next.js and this has been such a big time killer. It works fine with production builds since HMR isn’t a factor.

The above hack that krolow shared for rebuilding metadata doesn’t work for me (v0.2.30). The only relief I can get is to monkey patch my local file node_modules/typeorm/connection/Connection.js with this change: https://github.com/typeorm/typeorm/pull/5627/files

For posterity I wanted to drop a note about this. I revisited this today and it seems like I can skip the monkey patch by adapting the solution from: https://github.com/typeorm/typeorm/issues/6241#issuecomment-663786214

In my prepareConnection()/ensureConnection() function, when I find an existing connection AND I’m in a non production environment I apply this little hack. *insert sigh of relief* 🤞

         if (connection?.isConnected) {
             console.log('DB existing connection found.');
+
+            if (process.env.NODE_ENV !== 'production') {
+                // eslint-disable-next-line @typescript-eslint/ban-ts-comment
+                // @ts-ignore
+                connection.options.entities = Entities;
+
+                // eslint-disable-next-line @typescript-eslint/ban-ts-comment
+                // @ts-ignore
+                connection.buildMetadatas();
+
+                if (connection.options.synchronize) {
+                    await connection.synchronize();
+                }
+            }
+
             return connection;
         }

I’m also using Next.js and this has been such a big time killer. It works fine with production builds since HMR isn’t a factor.

The above hack that krolow shared for rebuilding metadata doesn’t work for me (v0.2.30). The only relief I can get is to monkey patch my local file node_modules/typeorm/connection/Connection.js with this change: https://github.com/typeorm/typeorm/pull/5627/files

Confirming downgrading to 0.2.22 worked for me.

I don’t think this is an issue caused by changes on NestJS’s side.

First time I hit this problem was back in March when upgrading TypeOrm to make use of the new soft-delete feature. I did not update NestJS back then nor since, but the app still broke when attempting to go above 0.2.22.

In my case it was pretty clear isolated breakage on TypeOrm’s side starting from 0.2.23.

Here’s a small example repository that exhibits this problem: https://github.com/tuhlmann/typeorm-entity-not-found

@pleerock @millsmcilroy Is there any update on this issue?

Would a (kind of) minimal example help you find a solution- or tell me how I can persuade typeorm to accept my entities?

I took the better half of the day to strip down my NestJS application to a small example app with just one entity.

I added 2 start scripts:

• if I start the app with ts-node-dev and point entities to the /src/**/*.entity{.ts,.js} directory or to the Entity class, this works fine.
• if I start by compiling to JS and then point node to the compiled JS or the Entity class, this fails.
  • if I point the entities property to the source ts files (not the compiled output) this also works, but it fails in the real app with multiple entities.

Not sure if this problem has to do with ts-config paths that I’m using in the scripts below.

Should the entities property point to the TS source files or the generated JS output, what is the recommended way?

Please let me know how I can help to resolve this issue.

Thank you!

–

This is the start script that works:

"dev:server2": "cross-env NODE_ENV=development ts-node-dev --type-check --no-notify --project tsconfig.server.json --respawn --transpileOnly --all-deps -r tsconfig-paths/register ./src/server/main.ts"

This is the more involved start script that fails:

"dev:server": "tsc-watch -p tsconfig.server.json --onSuccess \"cross-env TZ=utc TS_NODE_PROJECT=tsconfig.server.json node -r tsconfig-paths/register -r ts-node/register/transpile-only dist-srv/server/main.js\""

i am not using serverless, and have this issue aswell. last working version, as others, is 0.2.22

Is there any update on this issue?

Same for me (NestJS 7 server). I tried to mitigate the issue by loading the entities directly, not via a glob pattern string, but setting up an array of all the entities. But the issues remains.

I’m willing to change my code accordingly if I knew what in my source is causing the issue. For now only sticking to the previous version is the only workaround I found.

I encountered the same issue with postgres + nestjs and spent few hours to debug Connection.js I will downgrade to 0.2.22 until this is resolved. Thanks.

Issue you have might be something specific to your setup. I do use hot reload in some of my projects and never had issues with it.

I’ve been using 0.2.45 and the problem persists. I haven’t tried the solution by @jedireza but I did downgrade to 0.2.22 and it’s working but I now have severe package levels. What a sadness, Very tempted to diff between 0.2.22 and 0.2.23 and see what the hell happened.

If you’d like to monkey patch it you can. This will break in many, many cases. For example, changes to entities will not be reflected after a reload.

Your best bet, imo, is on any reload is to close the connection & open a new one. This is because we don’t support re-building the entities.

Just to chime in for anyone else reading, this is the simplest helper function that I could think of to bust HMR issues with TypeORM entity classes in Next.js:

let connectionReadyPromise: Promise<void> | null = null;

function prepareConnection() {
  if (!connectionReadyPromise) {
    connectionReadyPromise = (async () => {
      // clean up old connection that references outdated hot-reload classes
      try {
        const staleConnection = getConnection();
        await staleConnection.close();
      } catch (error) {
        // no stale connection to clean up
      }

      // wait for new default connection
      await createConnection(); // usual connection options go here
    })();
  }

  return connectionReadyPromise;
}

Then in any server-side code I do await prepareConnection() before performing any DB-related calls (which is similar to what above commenters suggest as well). I put it in its own file for easy inclusion, like src/db.ts.

I can confirm that this works with NextAuth on my codebase; should also work with any other HMR-enabled server solution. What I like about this, aside from the small size, is that the DB connection is simply restarted without doing any “surgery” on the entities list, updating metadata, etc. Perfectly fine for development mode.

@imnotjames I’ve set up this repo a while back: https://github.com/tuhlmann/typeorm-entity-not-found

It contains NestJS and it may well be that Nest is part of the problem as has been pointed out in this thread. Other than that I tried to keep it minimal. A description of how to start and the expected behavior is in the master branch’s README.

I have updated the sample application with a branch that uses mikro-orm instead of typeorm. Seems to work well enough: https://github.com/tuhlmann/typeorm-entity-not-found/tree/mikro-orm-v4

I also added a Sequelize branch, but compared to Typeorm that feels a bit clumsy to use. Not so mikro-orm.

@pleerock Any news on this, any advice how to change the code to still be able to use the latest typeOrm?

@pleerock I’m also not using serverless. I’m running a Nest 7 / NodeJS server. I’m fine with changing my code, but I can’t find what goes wrong and why the new version doesn’t find my entity files any more. If it helps, this is my build & run command from package.json. From the built JS structure I read the entities (not from the source TS):

"dev:server": "tsc-watch -p tsconfig.server.json --onSuccess \"cross-env TZ=utc TS_NODE_PROJECT=tsconfig.server.json node -r tsconfig-paths/register -r ts-node/register/transpile-only dist-srv/server/main.js\""

I get the feel that maybe the paths I define in tsconfig.json mess with the entity detection somehow, but that’s just a feeling…

@YoonSeongKyeong , I left a note on the PR but nobody from the TypeORM team are responding yet… this issue looks the same as the issue I posted 3 weeks ago: https://github.com/typeorm/typeorm/issues/5592

also see this thread: https://github.com/typeorm/typeorm/issues/5592, not resolved yet