#96 #90 type information provided is wrong.

#90 deasync.await implements an unhandled reject.
https://github.com/abbr/deasync/pull/90/files#diff-168726dbe96b3ce427e7fedce31bb0bcR77

@abbr

Thanks for the pr. I am ok for the ts but reluctant to add promise and await because they conceptually conflict with deasync. What's the use case that requires deasync support promise?

Simultaneously provide users with asynchronous and synchronous.

async function execCommand() { /* ...code... */ }
function execCommandSync() { return deasync.await(execCommand()) }

If you really don't want to accept Promise support. I will remove the Promise support. @abbr

@abbr

Thanks for the pr. I am ok for the ts but reluctant to add promise and await because they conceptually conflict with deasync. What's the use case that requires deasync support promise?

In what way do they "conceptually conflict" ? The whole point of deasync is to be able to run async code synchronously, isn't it?

For example, suppose you have the following and you need to have to run it in a synchronous context:

async function foo() {
 return true;
}

My expectation was I'd be able to then do this in a place where I cannot make a method asynchronous in order to use await (and an IIFE is not a viable solution):

const syncFoo = deasync(foo);
let result = syncFoo();
somethingElse(result); // won't run until the promise from foo resolves

But this gives various type errors. I haven't actually tried running, but presumably if TypeScript is complaining about it, then deasync as a library can't currently do the one use case I actually need it for.

This is shocking to me, given the library is described as DeAsync turns async function into sync. Async functions by definition return promises... The example with child_process.exec might be asynchronous process creation, but it is not an async function; it immediately returns the ChildProcess object!

I haven't actually tried running

just try, for science ; )

alternatives to deasync: terser/terser#801 (comment)