fix(gatsby): context.nodeModel.runQuery should return [] instead of null

[kartikcho]

As of now, context.nodeModel.runQuery returns Promise<null>, but the documentation specifies type Promise<Node[]> to be returned.

This PR resolves #25857 by updating the default return statement.

[kartikcho]

@vladar could you provide more context on these tests that seem to affect the change in this PR. Thanks!

gatsby/packages/gatsby/src/schema/__tests__/run-query.js

Lines 747 to 749 in 09b3688

	// Nothing is lt null so zero nodes should match
	// (Note: this is different from `lte`, which does return nulls here!)
	expect(result).toEqual(null)

gatsby/packages/gatsby/src/schema/__tests__/run-query.js

Lines 942 to 944 in 09b3688

	// Nothing is gt null so zero nodes should match
	// (Note: this is different from `gte`, which does return nulls here!)
	expect(result).toEqual(null)

[vladar]

Thanks for the PR! I think you should modify those tests to expect [] vs. null (as that's effectively what we change here).

But as I mentioned in the issue this is likely a breaking change, so we'll keep this PR open until the next major.

[pvdz]

Like @vladar said, this is a small but breaking change that we can't apply on a patch or even a minor version bump.

I would 💜 this PR when we're ready to bump the major because the distinction is annoying to me (I've messed with this code a lot) and I think it's only there because the original filtering library (sift) did it this way.

But an API is an API and even though the change looks benign, you can bet there's code out there that relies on this behavior.

[pvdz]

iirc there were one or two other places where this happens (returning null vs returning an empty array) but maybe I already unified those into this check here.

[kartikcho]

What do you want to update here @pvdz?

[pvdz]

I'm going to put this PR in draft mode as we won't be merging it any time soon. Rest assured that I really want this PR merged once we can!

[muescha]

should then the docs be updated to reflect the current state (with a deprecation warning that it would change in 3.0)?

[pvdz]

It's been like this for so long that I would kind of suggest to leave it as is for now. But if you're set on updating them then you could add a note that we plan to eliminate this inconsistency in a future major bump.

[kartikcho]

Thanks for still working on getting this in @vladar, let me know if I can be of help in any way!

[vladar]

Thanks for the PR and let's merge it, finally! 🎉