Why was the custom repository syntax changed?

[nimloth05]

I'm currently migrating from 0.2 to 0.3 and noticed that the syntax for custom repository was changed. I personally find this change very odd but I assume typeorm devs have a perfectly fine explanation for this - I lack to find it though. Remark: I know that this issue is not a documentation issue per se but SO is not the place to discuss things that's why I decided to post it here.

Where I'm coming from: My project only uses a single relational database with various small custom repositories.

Here is a simple example repository from 0.2:

import {User} from "../bl/user";
import {EntityManager, EntityRepository, Repository} from "typeorm";

@EntityRepository(User)
export class UserRepository extends Repository<User> {

  findByEmail(email: string): Promise<User | undefined> {
    // Implementation not relevant
  }

  isEmailAlreadyInUser(email: string): Promise<boolean> {
      // Implementation not relevant
  }
}

export function getUserRepository(manager: EntityManager): UserRepository {
  return manager.getCustomRepository(UserRepository);
}

New 0.3 version:

// I have to manually create a type so UserRepository exists in type space.
export type UserRepositoryType = Repository<User> & {
  findByEmail(email: string): Promise<User | null>;
  isEmailAlreadyInUser(email: string): Promise<boolean>;
}

// this UserRepository only exists in value space. Without my previous type declaration I cannot return it from my helper function.
const UserRepository: UserRepositoryType = AppDataSource.getRepository(User).extend({
  findByEmail(email: string): Promise<User | null> {
    // Implementation not relevant
  },

  isEmailAlreadyInUser(email: string): Promise<boolean> {
    // Implementation not relevant
  }
});

// Helper function, so clients are shielded of typeoRM access.
export function getUserRepository(manager: EntityManager): UserRepositoryType {
  return manager.withRepository(UserRepository);
}

I'm wondering two things:

• Why was the class declaration style dropped? It seems much more "TS like" then the other. (Which seems more JS like but JS doesn't know about type space...)
• Why is the repo bound to a datasource? A repo - as I use it - is a concept from DDD in which case it encapsulates certain aspects of my business logic. Why should this logic change depending on the database I use?

As I sad before, this is not a critic since I'd like to understand the reasoning behind the change first.

[joran-github]

I started just today my migration from typeorm 0.2 to 0.3 and I had exactly the 2 same remarks.

The fact that repo is linked to a datasource is a pain.
For my project, I have e2e tests that use a test datasource (sqlite in memory).
What is the way with this new version to select datasource and reuse same repository ?

[nimloth05]

@joran-github Wouldn't it be possible to do something like this:

function getDatasource(): Datasource {
   return process.env() === "test" ? TestDatasource : ProductionDatasource;
} 

Usage:

getDatasource().getRepository(...).extend({...});

Not cool but better to duplicate everything - if this works.(?)

Today I had to refactor one of my custom repo methods. Webstorm totally blew it because it was not clear what to refactor - since the type is missing.

So again, I really like to know, why the class syntax was dropped. Since, until now, I only encountered negative effects of this change.

[joran-github]

@nimloth05
I was not so confident in using an environment variable because if you run the tests without this variable set, you can destroy your production database.
However, I think there is no other way so I will do it and add an assert in "beforeAll()".

Defintely, if any contributor read us, could you please give us some clues about those 2 things:

• Why was the class declaration style dropped? It seems much more "TS like" then the other. (Which seems more JS like but JS doesn't know about type space...)

• Why is the repo bound to a datasource? A repo - as I use it - is a concept from DDD in which case it encapsulates certain aspects of my business logic. Why should this logic change depending on the database I use?

[TheUnderScorer]

I was still able to use the old Repository syntax with some changes to the code:

import {Repository} from 'typeorm';
import {TaskModel} from './TaskModel';

// Note lack of "@EntityRepository" decorator
export class TaskRepository extends Repository<TaskModel> {
   //your repository methods
}

And then creating it like this:

import {TaskRepository} from './TaskRepository';
import {TaskModel} from './TaskModel';
import {DataSource} from 'typeorm';

const connection = new DataSource({...})

 const taskRepository = new TaskRepository(
   TaskModel,
   connection.createEntityManager()
);

So far it seems to be working fine for me, though I'm not sure if it won't create some issues with more advanced usages.

[nimloth05]

@TheUnderScorer Cool! Does this also work inside transactions?

[TheUnderScorer]

In theory, it should 😄 . But you would have to create the repository like this:

import {TaskRepository} from './TaskRepository';
import {TaskModel} from './TaskModel';
import {DataSource} from 'typeorm';

const connection = new DataSource({...})

connection.transaction(async transaction => {
  const repository = new TaskRepository(TaskModel, transaction, transaction.queryRunner);
  
  // Do stuff...
})

[ppedro1]

Since this thread is probably the most comprehensive source of information about this issue (regarding custom repository type space), I have found that the only reasonable and easy to use method in my use case is:

class SomethingRepository {
    static repository = DataSource.getRepository(SomethingEntity); // can use await SomethingRepository.repository.findOne(); etc
    
    static async someRandomMethod () {
        return this.repository.findMany(); // Type will be SomethingEntity[];
    }
}

I would also very much want to know about the reasoning behind this change, and how it would be possible to implement the new changes correctly so that we don't lose type space/IDE hints.

[ankyeongeun]

typeorm.providers.js file is changed. there was getCustomRepository(entity), but now it's gone...

[DiOps]

I found a way on how to implement custom repositories with the new version. I answered this question on Stack Overflow. Maybe this might help someone: https://stackoverflow.com/questions/72549668/how-to-do-custom-repository-using-typeorm-mongodb-in-nestjs/72887316#72887316

[niklilland]

I am very interested in learning the why behind this changed. After digging around for a bit I haven't been able to find any kind of conversation or documentation on the goal behind this change, other than a line in the release notes stating that the old way is deprecated.

[slaviqueue]

It's strange that the old simple way for creating custom repos via inheritance was removed, and it's funny that nothing special is going on in extend. Why can't initialisation be left inside getCustomRepository?

    /**
     * Extends repository with provided functions.
     */
    extend<CustomRepository>(
        custom: CustomRepository &
            ThisType<Repository<Entity> & CustomRepository>,
    ): Repository<Entity> & CustomRepository {
        // return {
        //     ...this,
        //     ...custom
        // };
        const thisRepo = this.constructor as new (...args: any[]) => typeof this
        const { target, manager, queryRunner } = this
        const cls = new (class extends thisRepo {})(
            target,
            manager,
            queryRunner,
        )
        Object.assign(cls, custom)
        return cls as any
    }

[nimloth05]

Does someone know if there is an active fork of 0.2? Or what did you guys do? Did you migrate? Do you keep 0.2? In our project we see two options: keep 0.2 or use something different. Preferably a fork 0f 0.2

[niklilland]

We use NestJS, so our custom repositories are becoming custom providers without too much trouble. There is a gist someone posted in another issue that another dev is using to aid in migrating our custom repos to Nest providers, in case it's helpful:

nestjs/typeorm#1302 (comment)