Ability to override the global JS SDK within the Server runtime

[dplewis]

New Feature / Enhancement Checklist

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

Current Limitation

It's currently not possible to change the JS SDK that ships with each Parse Server release.

Feature / Enhancement Description

Add a ParseSDK configuration to change the global Parse within the server here.

const Parse = require('../../node');

await ParseServer.startApp({
  ...
  parseSDK: Parse
});

Parse.Cloud.define('Override', () => {
  const object = new Parse.Object('test'); // Should use parseSDK instead of builtin SDK
});

Example Use Case

You can use the latest JS SDK without waiting for a new release. It would work if you need to use your own custom fork of the SDK. This is useful in the JS SDK test suite as changes made can be used in cloud code functions immediately. Could be used for #8787

Alternatives / Workarounds

3rd Party References

[parse-github-assistant]

Thanks for opening this issue!

• 🎉 We are excited about your ideas for improvement!

[mtrezza]

It's currently not possible to change the JS SDK that ships with each Parse Server release.

I would say for good reason! The JS SDK is being used as an internal part of Parse Server. We are testing and releasing with a specific JS SDK. If we allow this to be overridden, then we may need 2 compatibility tables for the JS SDK, one for client use, another one for internal use. Maintaining such a compatibility table would require immense CI efforts, as we'd need to start testing Parse Server against multiple JS SDK versions.

I believe an effort into #8787 makes more sense. Once Parse Server does not depend on the JS SDK anymore, and its only dependency arises from the use of Cloud Code, then I believe the introduction of an option to set a specific SDK version makes sense. Because then there doesn't have to be any compatibility match anymore between the server and use of the JS SDK for Cloud Code, it's more isolated like an adapter.

[dplewis]

This feature is mainly used for the JS SDK test suite internal use and experienced developers to used at their own risk in cloud code only and would not touch the rest of the code base. It wouldn't conflict with #8787 in the future as it is an optional feature.

I believe an effort into #8787 makes more sense

This would be awesome but Parse Server is so tightly coupled with the JS SDK outside of cloud code it's going to take a lot of work to get this done. Parse.Error alone is used everythere.

[mtrezza]

experienced developers to used at their own risk in cloud code only

I agree, but in that case there is no application for production use. We'd need to add a big warning label to that option and discourage production use. For experimental use, an experienced developer can fork and modify as needed.

Parse.Error alone is used everythere.

We have parse-community/Parse-SDK-JS#1269 for this.