Vladimir Grenaderov

> "import.meta.resolve" does [not resolve subpaths.](https://github.com/iambumblehead/esmock/pull/179) [The test](https://github.com/iambumblehead/esmock/blob/master/tests/tests-node/esmock.node.test.js#L32-L42) creates a call like `await import.meta.resolve('#sub', parent)` > It supports:

> there will be less maintenance, if we wait for import.meta.resolve to be stable and complete before using it. --experimantal-loaders is experimental too, so waiting can be looong )

@iambumblehead I will approve after few small fixes ) And yes, import.meta.resolve returns all paths:

> It might be better if we _do not enable_ `import.meta.resolve`, since resolvewithplus will be embedded and is already being used. Not sure. Tests pass when `import.meta.resolve` is used so...

> the comment here indicates `import.meta.resolve` is not reliable [nodejs/node#30682 (comment)](https://github.com/nodejs/node/issues/30682#issuecomment-950047088) and based on discussions I've read, it hasn't been updated at nodejs upstream in a long time maybe a...

What is the reason to check? For my understanding, it was created to avoid setup mistakes (for users) and to make predictable environment (for author). So, this check in not...

I mean that esmockIsLoader() implementation is a bit naive, and relates on way how to loader added to Node loaders chain. And my proposal is to use direct interaction with...

> @koshic an interesting and clever idea :) yes I like that Yep, it's an unblockable pipe between loaders & 'user space'.

Even this is expected behavior, overall output looks ambiguous: ```shell ➜ main git:(master) ✗ node 1.cjs ✔ bug (10002.205177ms) ℹ Warning: A resource generated asynchronous activity after the test ended....

> I guess we can add a stack trace to this warning, Yeah, it would be nice. > are you interested in sending a PR? Sorry, no - I can't...