AggregationOptions types for aggregate queries broken for sample (any maybe others)

[magnacartatron]

New Issue Checklist

• I am not disclosing a vulnerability.
• I am not just asking a question.
• I have searched through existing issues.
• I can reproduce the issue with the latest version of Parse Server.

Issue Description

Parse.Query type definitions broken for AggregationOptions.
In particular sample. This is because the type definitions expect

sample: {
size: 25
}

but to get the actual result you need to use

$sample: {
size: 25
}

This however requires to use @ts-ignore

Steps to reproduce

Create a pipeline of type AggregationOptions with type sample e.g.

const pipeline = {
    sample: {
      size: 25,
    },
  };

Then use an aggregate query.

const query = new Parse.Query(Item);
const randomItems = await query.aggregate(pipeline);

Actual Outcome

ParseError: Invalid aggregate stage 'sample'.

Expected Outcome

List of items

Environment

Server

• Parse Server version: `6.3.1
• Operating system: macOS
• Local or remote host (AWS, Azure, Google Cloud, Heroku, Digital Ocean, etc): Local

Database

• System (MongoDB or Postgres): MongoDB
• Database version: 6.0.0
• Local or remote host (MongoDB Atlas, mLab, AWS, Azure, Google Cloud, etc): Local

Client

• SDK (iOS, Android, JavaScript, PHP, Unity, etc): Cloud Code Javascript
• SDK version: 4.1.0

Logs

[parse-github-assistant]

Thanks for opening this issue!

• 🚀 You can help us to fix this issue faster by opening a pull request with a failing test. See our Contribution Guide for how to make a pull request, or read our New Contributor's Guide if this is your first time contributing.

[mtrezza]

We switched to using the original MongoDB stage names in #7338, so this is expected behavior. If the TS error comes from the TS definition of a 3rd party (outside of the Parse Platform org), then you'd need to open an issue there.

[magnacartatron]

Oh okay no problem, is @types/parse not managed by you guys?
I'll raise a ticket with them.
Also do you have any recommendations for how to introduce type safety in typescript parse node? I see you use flow in the parse-server repo but I'm not sure if that's going to work for typescript.

I've raised a ticket with them

[mtrezza]

It is not. In fact we are working on parse-community/Parse-SDK-JS#2012 to add our own TS definitions for Parse JS SDK (which is where the Parse.Query methods are defined). Please feel free to give a hand there if you want. They will be build automatically from code, instead of having to maintain them separately. Hence we do not make an effort to open issues with 3rd party TS libraries.

If I understand your issue correctly, the TS definition you are using is parsing the pipeline. We do not intend to do that in our own types, because this is native MongoDB syntax that the developer is responsible for checking.

[magnacartatron]

@mtrezza I agree, and I've just seen it in 4.2.0 alpha and I'm very excited as @types/parse has always been a bit behind.
It's the old issue of brining new developers on board and the clearer and more discoverable the code is, the less errors are made.
Also I know that maintaining documentation is hard, but without actually delving in the various parse libraries codebases it's literally impossible to workout how certain options that one would assume should be straightforward should work.

Good typing would nearly remove all need for detailed documentation.