-
-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refine query selector to highlight unexpected query keys #14764
Conversation
Previously, there was a catch-all case in RootQuerySelector which would accept any key with type "any". This still allows nice IDE typehints, but can lead to bugs where the incorrect key is used for a filter with no warning that the key is clearly wrong. With this PR, only keys that contain a "." are unsafely typed as any, which should reduce the blast radius of the hacky types dramatically.
@hasezoey @IslandRhythms please let me know if there's anything I can do to help get this merged, or if there's any blocking concerns (can't tag reviewers) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i am partial to this, but i think the new types only allow a single level of nesting.
in any case, to get this merged (not considering if this is even wanted or not), you should probably add some ts tests for this new addition (and fix existing ones). some tests to consider:
- that there is a error on a unknown key
- 1 level nesting should give
any
- more than 1 level nesting?
- overwrite to allow the old behavior in addition to known properties?
@hasezoey Thanks for the feedback! I've fixed the existing tests by adding a I've also added some new test cases covering those you mentioned as well as some others I thought would be relevant. Addressing some comments:
It actually allows anything containing at least one "." to retain the previous behavior, so multiple levels of nesting should work fine still
I'm not sure how I could go about supporting this, and that's my main concern with this change that I'm open to feedback on. Only approach I could see is a separate version of functions with the other types, which feels far too messy. I'm not if this change would need to be delayed until a breaking major version; it seems possible it would cause type errors for many users, but also likely that it would catch many bugs in doing so. I could fallback to implementing this as a patch in my repo's types, but was hoping it could help others more broadly. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. I think this can be a reasonable compromise between Mongoose's flexible queries and strict type checking. In the interest of caution, I'll merge this into 8.6 branch though. We may end up having to revert this if it causes unforeseen consequences.
@alex-statsig it looks like there's some test failures against 8.6 branch, the crux of the issue is likely 8.6 changing the I think the fix would be to just update queryhelpers.test.ts to correctly type |
Summary
Previously, there was a catch-all case in RootQuerySelector which would accept any key with type "any". This still allows nice IDE typehints, but can lead to bugs where the incorrect key is used for a filter with no warning that the key is clearly wrong.
With this PR, only keys that contain a "." are unsafely typed as any, which should reduce the blast radius of the hacky types dramatically.
Examples
Previously, the following would be a valid type:
Now, the above case gives a type error for "invalidKey".
Note that a case such as this will still be accepted (since its hard to properly type any nested queries):