getRawOne return type ought to include undefined

[osdiab]

Documentation Issue

What was unclear or otherwise insufficient?

the typings for getRawOne allow any type parameter T and blindly returns a Promise<T>, so if you use it and no matching db row is found, it will happily lie to you and say that the row is present via the type system. this isn't wrong, per se, but it's an easy footgun.

Recommended Fix

make the typing of getRawOne return the parameterized type | undefined, in case there are no rows present. users of typeorm can use the non-null assertion syntax if they really think it's present.

Additional Context

my company's app had unexpected 500s from this, but we're used to TypeORM making undefined access errors go away, because that's something it's particularly good at, if your typings don't do unsafe things like this.

Are you willing to resolve this issue by submitting a Pull Request?

• Yes, I have the time, and I know how to start.
• Yes, I have the time, but I don't know how to start. I would need guidance.
• No, I don't have the time, although I believe I could do it if I had the time...
• No, I don't have the time and I wouldn't even know how to start.

[macksal]

Simplest fix would be to change the return type to Promise<T> | undefined in this file and fixing any type errors which propagate from there.

In the long-term I think it's best to enable tsconfig's noUncheckedIndexAccess. It's a great feature to prevent issues like this. For context it makes an index access to a value of type T[] return T | undefined. In this case, that would generate an error with the type signature of getRawOne.

[imnotjames]

It probably shouldn't even be Promise<T | undefined> but.. that's a separate issue. - oh wait, T is definable as a generic on the function. That makes sense.

[jdemangeon]

Hi guys!

Just to notice, forcing undefined as a possibility is not right from a strict SQL point of view.
You can actually request manual select from the query (here's an example with a COUNT):

const queryBuilder = this
      .createQueryBuilder('something')
      .leftJoin('something.otherthing', 'otherthing')
      ......
      .select([
        'COUNT(DISTINCT something.id) AS something_count',
        'COUNT(DISTINCT otherthing.id) AS otherthing_count'
    ])

So, in this case, and to avoid TS errors, I must use a non-null assertion for no good reason 🤷‍♂️