fix: add Meteor.applyAsync typings

[Julusian]

Typescript typings for Meteor.callAsync were added a while ago, but Meteor.applyAsync was missing.

Meteor.apply has been refactored a bit to allow for sharing types across the two, and jsdoc has been copied from the implementation to make it available to intellisense.

[CLAassistant]

All committers have signed the CLA.

[radekmie]

@Grubba27 By looking at this code I think it's possible that asyncApply returns synchronously when the callback is present. It'd have to be investigated separately, but how about not documenting this callback in applyAsync at all? I know I asked about this before (#12196 (comment)), but maybe this should be revisited?

[Grubba27]

Maybe @denihs is the best person for pinging in this case.
I think applyAsync should not accept a callback.
Regarding the check, that is a great question that we should have discussed.
having the async version with callback can help those projects that just want to migrate and things just work™️ but at the same time blocking the use of it forces the end user to do the migration in the right way I guess

[denihs]

We're changing a lot in this function for release 3.0.

This code wouldn't be valid anymore. I'd wait for the final version before creating the types.

[Julusian]

If theres going to be any further 2.x releases it would be nice to have some types there, I encountered this when updating a project to 2.12 and wanted to replace some Meteor.apply() calls with Meteor.applyAsync().

[radekmie]

Then I'd rather add it now, without the callback, and then change it for 3.0.

[zodern]

If I understand the api correctly, the promise is used for the stub result, and the callback is used for the server result.

[radekmie]

Then this should be documented. But honestly I’d expect it to be the opposite? Mostly because the returned Promise will be used more than the callback, I think.

[zodern]

This is off topic, but for zodern:relay I am considering doing something like this so we don't need callbacks:

const promise = createProject();
const stubResult = await promise.stubPromise;
const serverResult = await promise;

// Another option.
// The returned object (which also is a promise) is the same thing as the previous example,
// but it also has a property for `serverPromise`
const { stubPromise, serverPromise }  = createProject();
const stubResult = await stubPromise;
const serverResult = await serverPromise;

[Grubba27]

The first one is the default for many people.
like this:

const result = await createProject()

Exposing the second one may lead to unnecessary use of the stubPromise?

[zodern]

Sorry, I missed your message @Grubba27.

The second example still directly returns a promise to get the server result so you still can use const serverResult = await createProject(). If the stub result isn't needed, I assume it generally wouldn't be unnecessarily used since it takes more code. The stubPromise and serverPromise are properties added to the returned promise.