deasync hangs with --experimental-specifier-resolution=node

[daveisfera]

• Version: 14.12.0
• Platform: macOS 10.15.6
• Subsystem:

What steps will reproduce the bug?

1. Load test repo: https://github.com/daveisfera/mocha_deasync
2. Run yarn test and verify it works with esm
3. Run yarn spec and verify that it hangs when node's ESM support

How often does it reproduce? Is there a required condition?

100%

What is the expected behavior?

Runs to completion like with esm

What do you see instead?

Hangs while resolving the promises

Additional information

I was looking for an alternative approach to work around #35103 and ran into this issue

[daveisfera]

Also, just tried without --experimental-specifier-resolution-node (i.e. use an explicit path in the import) and it hangs as well

[addaleax]

@daveisfera I’ll close this because what deasync is doing is not supported by Node.js (this is not a secret and they know that – do not use it in production software, if you can avoid it at all). You can report this to them, though.

[daveisfera]

That makes sense, but is there a recommended pattern for how to load settings using promises before the rest of an application is initialized, because relying on deasync is the best option we've had so far and worked with esm for quite some time, so we'd love to switch to a "better" solution, but unfortunately haven't found one yet

[trusktr]

I can verify that --experimental-specifier-resolution=node crashes only when using deasync (for some reason, import promises will never resolve in that case).

But when not using deasync, import promises resolve fine.

This is all while using node --experimental-specifier-resolution=node.

[trusktr]

I updated abbr/deasync#134 with a reproduction, and also showed there that avoiding use of the --experimental-specifier-resolution=node flag indeed does work while using deasync. @daveisfera Maybe you had another issue too.

Not sure if it may help, but also check out how I'm waiting for the promise in that example's code; it could be (but I'm not sure) that the way I'm using deasync (while not using --experimental-specifier-resolution=node) to wait for the promise without manually ticking the clock leads to mine working. The deasync documentation did not specify how to do it the way that I did, but instead the deasync README shows an example of doing it with manual clock ticking, and it could be that the difference between that approach and mine (which wraps the promises with a callback function) may be why mine works and yours didn't (this is just a guess, but maybe worth exploring).