Guy Bedford

Also I do think it's a critical part of the implementation since `require.resolve` is such a standard workflow in CommonJS. I really hope we don't allow the lack of collaborative...

I've added the meeting agenda label, let's try to discuss this further.

The major blocker to `import.meta.resolve` is the sync / async issue between what is proposed for the browser and what is needed for Node.js. What do people think about just...

The test suite should be based on `resolve(specifier, context) -> Promise` being tested, and possibly also a `getFormat` - effectively just like the loader hooks implementation themselves. So I would...

Just to take a step back here - it would really help to understand what the exact use cases / problems / user stories are that this feature solves. Is...

> no, it’s to enable anyone to choose any extensions they want for anything Why is this a goal? Who is "anyone" here? I would really appreciate it being phrased...

> if we're taking that ability away from them for ESM, we're saying "we know better than you do how extensions should work" - and in that case, why not...

> @guybedford that same thing applies to a "type" or "mode" or "exports" field in package.json - you always have to know the possibilities, and build your tooling to accomodate...

> I'm not sure what you mean by "compiles at runtime"; there's nothing about this proposal that forces that, Ahh, sorry I was referring to @MylesBorins's proposal here. Just to...

> Even with no first class support, you could write an esm package that compiles some code at startup and then imports it using dynamic import. Not really sure how...