Typescript (TS) global approach/migration (Parse server and JS SDK)

[Moumouls]

New Issue Checklist

• Report security issues confidentially.
• Any contribution is under this license.
• Before posting search existing issues.

Issue Description

The official releases of parse-server and Parse JS SDK now include TypeScript types. However, these definitions differ from and are incomplete compared to the @types/parse package.

Currently, upgrading parse-server and Parse JS SDK in a fully typed codebase leads to type conflicts and many type errors.

Developers working in TypeScript codebases who want to upgrade to benefit from new features, fixes, and security updates will not be able to do so easily.

The @types/parse package worked quite well previously.

TypeScript support is important, but Parse has a non-standard architecture:

• Parse Server relies on Parse SDK
• Parse SDK is used as a singleton and has additional capabilities when used server-side with parse-server (Cloud hooks)
• @types/parse already exists with well-defined types

I think the best plan would be:

1. Contributing to @types/parse to fill all missing areas, and updating documentation to ask parse-server TypeScript developers to install @types/parse if needed. We could also consider creating @types/parse-server that extends @types/parse features for server-specific functionality (like cloud code).

2. Once @types/parse and/or @types/parse-server are complete, we can copy the type definitions directly into parse and parse-server.

3. Begin migrating some JS files to TypeScript to properly transition from .d.ts files to a truly typed project.

Bonus: If we lack the resources to migrate JS to TS files, we can still maintain fully working .d.ts files that are easy to maintain in each repository (parse-server and Parse JS SDK).

If this plan seems acceptable, it means we should revert some of the TypeScript work done on parse-server and Parse JS SDK.

[parse-github-assistant[bot]]

🚀 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.

[Moumouls]

ping @mtrezza @dblythy @dplewis

[mtrezza]

Point (1) is outside of our scope. It's a 3rd party repository and anyone is free to use it or contribute to it. We just need to be mindful that any efforts spent by contributors on that 3rd party repo could be spent on bringing our native TS migration forward, so I don't see any coordinated endorsement here.

We started this migration before the availability of agentic tools. I wonder how much work it would really take today to bring the types closer to the 3rd party types. Some difference is acceptable. It's worth a try to feed the typed file and our code into an agent and see how much it can auto-adapt our code for compatibility.

For some of the namespaces we could cheat by using static type files that we manually edit, as long as the code structure is too complex to generate them automatically (JS SDK part of Parse Server). If a namespace of the SDK is only available server side then I think it's fine to offer that also client side for now, with a doc note that it only works in Cloud Code.

In short, maybe there is a way to use static type files for some parts that break TS compatibility, while keeping the current TS implementation for other simple parts. If we completely remove the TS implementation, then I'm afraid that it may not get picked up anytime soon and that would be a shame for the efforts that people have put into this so far. We could also disable the native types for now - without removing the whole implementation - until specific steps are taken that allow us to refine the types. For example the integration of the JS SDK in Parse Server, if that has to be removed first.

[Moumouls]

I think disabling types is a good idea as a quick fix

[mtrezza]

We can do that. What are the classes / namespaces where you see the most incompatibility to @types/parse? Are there just a few or is this an issue across the board?

[dplewis]

The issue I've seen come up is with the Parse.Cloud namespace. The easiest path is to add those types to the JS SDK.

I tried to add the types to Parse Server by extending the types from the JS SDK but I'm no typescript expert https://github.com/parse-community/parse-server/compare/alpha...dplewis:parse-server:cloud-ts?expand=1

[Moumouls]

i will try @mtrezza to generate a report via our internal mono repo

[tiavina-mika]

Is there any news or workaround around this issue?

[Moumouls]

@tiavina-mika No big news at the moment. I suggest that all impacted users use the standard “patching” approach with npm or yarn, and remove the “types” folder.

This way, your types won’t conflict with @types/parse.

At my company, we’re currently using this approach until the conflict is resolved.

I don’t currently have the time window to make a full review and completely fix the issue.