fix: Cloud trigger type errors for void returns and subclass constructors

[swittk]

Pull Request

• Report security issues confidentially.
• Any contribution is under this license.
• Link this pull request to an issue.

Issue

This both fixes a regression in cloud trigger return typings & fixes a longstanding issue when defining triggers on subclasses.
The current typings allow only for triggers to return something e.g. undefined, or the exact object class (which is generally likely the same request.object).

// This previously fine case would fail with the current typings, since it returns "void" instead of the currently required "undefined" return.
Parse.Cloud.beforeSave(MyClass, (req)=>{
  req.object.set('serverTime', Date.now());
})

However, the behaviour commonly used, and was accepted in the prior DefinitelyTyped-defined typings, was to simply not return anything and do mutations on the object e.g. request.object.set(...), which would mean a function with a return type of void. Since the typings do not allow for void returns, upgrading a prior codebase to a newer version of Parse JS SDK with built-in typings will cause errors.
Another thing that this fixes is for subclasses of Parse.Object that have non-optional arguments for types, Parse.Cloud triggers (e.g. Parse.Cloud.beforeSave) previously was typed using the new () => T syntax, which means anything with constructor arguments could not be typed. This now allows for us to do things like.

class A extends Parse.Object<{ a: string }> { constructor(arg:{ a: string } ) { super('A', arg); } };
// Previously this would complain that A does not fit the signature
Parse.Cloud.beforeSave(A, (req)=> { /* whatever */ })

Approach

Added void return type to Parse.Cloud typings.
Fixed type trigger class generic typings to allow for subclasses with constructors that have arguments.

Tasks

• Add tests

Summary by CodeRabbit

• New Features

  • Cloud Code hooks now accept class constructors as well as string class names for broader registration options.
  • Hook handlers may return void (synchronously or via Promise) in addition to previous return shapes, simplifying synchronous handlers.
  • Changes apply across triggers (save, delete, find, subscribe, login/logout, password reset, file operations, live query, connect).

• Tests

  • Added tests demonstrating constructor-based hook usage.

[parse-github-assistant]

🚀 Thanks for opening this pull request!

[parseplatformorg]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scanner	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[coderabbitai]

📝 Walkthrough

Walkthrough

Introduce a generic type alias ParseObjectConstructor and replace inline constructor signatures across Cloud Code APIs; widen many hook handler return types to allow synchronous void/undefined in addition to Promise/value returns. Update JSDoc and declaration files to match the new types.

Changes

Cohort / File(s)	Summary
Core CloudCode source src/CloudCode.ts	Add type ParseObjectConstructor<T extends ParseObject = ParseObject> = new (...args: any[]) => T;. Replace (new () => T) with ParseObjectConstructor<T> across Cloud hook APIs and broaden handler return types to include void/undefined alongside existing returns; update JSDoc.
Type declarations types/CloudCode.d.ts	Mirror source changes: add ParseObjectConstructor alias, update all Cloud hook signatures to accept `className: string
Tests / usage examples types/tests.ts	Add overload/example showing Cloud.beforeSave accepts a class constructor so request.object narrows to the subclass; minor test additions demonstrating type alignment.

Sequence Diagram(s)

(omitted)

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• fix: Parse.Object.createWithoutData doesn't preserve object subclass #2907: Adds/adjusts ParseObject constructor typing and related generic return types — closely related to the new ParseObjectConstructor<T>.
• fix: Add server-side Cloud Code types for parse/node #2855: Modifies CloudCode type declarations and hook signatures in the same areas updated here.

Suggested reviewers

• dplewis

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description check	✅ Passed	The description includes all required template sections, explains the issues and fixes comprehensively, and indicates tests were added.
Title check	✅ Passed	The title clearly and accurately summarizes the main changes: fixing Cloud trigger type errors to support void returns and subclass constructors.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (01dc94d) to head (4e084bc).
⚠️ Report is 22 commits behind head on alpha.

Additional details and impacted files

@@            Coverage Diff            @@
##             alpha     #2904   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           64        64           
  Lines         6235      6235           
  Branches      1481      1477    -4     
=========================================
  Hits          6235      6235           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In `@src/CloudCode.ts`:
- Around line 286-290: Add a file-level ESLint disable for the void-in-union
rule to src/CloudCode.ts so the numerous trigger declarations (e.g.,
beforeSave<T extends ParseObject = ParseObject>, and the other handler
signatures) can legally use void in their union return types; specifically,
insert a top-of-file comment disabling `@typescript-eslint/no-invalid-void-type`
(e.g., a file-level eslint-disable for that rule) before any imports or code so
all handler declarations in this file are exempt.

[swittk]

It seems the current TS ESLint doesn't like it when we do union to void; what should I do regarding this? Would an eslint ignore suffice or are we accepting the new behaviour of always needing to return undefined from a cloud function now..
Edit : Or should I follow the Code rabbit's eslint-disable suggestion? 😅

[swittk]

Is this OK for merge?

[mtrezza]

@coderabbitai suggest a PR title (changelog entry) for this PR.

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

@mtrezza, here are a few suggested PR title options for the changelog entry:

Option 1 (Concise):

fix: Support void returns and constructor params in Cloud trigger types

Option 2 (More descriptive):

fix: Allow void return types and parameterized constructors in Cloud triggers

Option 3 (Detailed):

fix: Broaden Cloud trigger handler return types and ParseObject constructor constraints

Option 4 (User-focused):

fix: Cloud trigger types now support void returns and subclass constructors with arguments

I'd recommend Option 1 or Option 2 as they strike a good balance between being concise for a changelog while clearly communicating both fixes: the void return type support and the ability to use ParseObject subclasses with required constructor arguments.

[mtrezza]

@coderabbitai For a fix, it should describe the issue, not the solution

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

@mtrezza, you're absolutely right! Here are revised PR title options that describe the issues:

Option 1 (Concise):

fix: Cloud trigger handlers without return values fail type checks

Option 2 (Both issues):

fix: Cloud trigger type errors for void returns and subclass constructors

Option 3 (More specific):

fix: Type check failure for Cloud triggers with mutations and no return value

Option 4 (Regression-focused):

fix: Regression causing Cloud trigger handlers to require explicit return

Option 5 (Dual issue):

fix: Cloud trigger typing rejects void handlers and parameterized Parse.Object subclasses

I'd recommend Option 1 for clarity and brevity, or Option 2 if you want to acknowledge both issues addressed in this PR.

[parseplatformorg]

🎉 This change has been released in version 8.1.1-alpha.3

[parseplatformorg]

🎉 This change has been released in version 8.2.0