Non-useful type for 'where' argument for @Entity decorator expression callback

[rcfox]

Describe the bug

Version 6.4.7 seems to have added some improved typing around entities. However, when creating a virtual entity using a callback expression, the where argument seems to be incorrect, or at least not useful. None of the fields are accessible because it appears to be checking typeof MyEntity instead of MyEntity.

My project has been extracting fields from the where argument to compose a dynamic query, and so this is preventing us from upgrading.

When inspecting the type of the @Entity decorator on a standard non-virtual entity, I can see that the resolved generic type is Entity<typeof MyEntity>. Is that expected?

Reproduction

@Entity({
  expression: (em: EntityManager, where, options) => {
    // As of Mikro-ORM v6.4.7:
    // type of `where` is FilterQuery<typeof Test>
    // Property 'foo' does not exist on type 'FilterQuery<typeof Test>'.
    //  Property 'foo' does not exist on type 'typeof Test'. [2339]
    return [{ foo: where.foo }];
  },
})
export class Test {
  @Property()
  foo!: string;
}

...

// In Mikro-ORM v6.4.6, this used to work:
const test = await this.em.find(Test, {foo: 'a'})
console.log(test) // [ Test { foo: 'a' } ]

What driver are you using?

@mikro-orm/postgresql

MikroORM version

6.4.7, 6.4.8

Node.js version

v22.14.0

Typescript version

v5.4.5

Operating system

Ubuntu Linux

Validations

• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord.
• The provided reproduction is a minimal reproducible example of the bug.

[B4nan]

// In Mikro-ORM v6.4.6, this used to work:

It still works, right? This is only a type issue, nothing changed in runtime behavior.

[B4nan]

Hmm I see the issue, but it's a bit tricky. It worked for you before because the where option wasn't type safe at all. Now when I fix the above, it still fails, because it is typed to FilterQuery which means "either an object or the PK value or an array of such", you can't just work with that as with an object, since it might not be an object.

It would work if we type it to ObjectQuery, which is always an object (a part of the FilterQuery union basically), but for that I'd have to ensure the parameter is always an object. I hope it wont break some other use cases, but I don't see another way out of this (except making things weakly typed again).

[rcfox]

Yes, the run-time behaviour is correct if I explicitly set the type where: any.

[rcfox]

Is there a way that the type could be narrowed? I agree, the way we were accessing this before was unsafe and just happened to work because of the way the FilterQuery was constructed.

[rcfox]

Well, I suppose an acceptable workaround for now is just to do something like this:

@Entity({
  expression: (em: EntityManager, where: unknown, options) => {
    if (!(where instanceof Object)) {
      throw new Error('expected FilterQuery to be an object');
    }
    if (!('foo' in where)) {
      throw new Error('expected foo argument');
    }
    return [{ foo: where.foo }];
  },
})
export class Test {
  @Property()
  foo!: string;
}

I feel like you'd have to be able to override the FilterQuery type that em.find uses to properly protect this, and that doesn't seem like it would be worthwhile for such a niche use case.

[B4nan]

I think it should be fine if we ensure we are feeding an object into the expression callback. Every query can be rewritten to an object, a scalar means its a PK search (e.g. { id: ... }), an array means AND query (e.g. { $and: [...] }). We already do that internally, but at a later stage (or maybe not, and just the types are not 100% correct internally, I actually think we do it before we pass the query to the driver where the expression callback is evaluated).

If there wont be any broken tests I will go with that approach, alternatively I will make the query option unsafe and make this change in v7.