Michał Gołębiowski-Owczarek

We discussed it today at the meeting. It seems for Webpack it may be enough to drop the `module` condition. That condition is already specified inside of the `node` one...

That said, I think we have an issue with Rollup. Per https://www.npmjs.com/package/@rollup/plugin-node-resolve: > Additional conditions of the package.json exports field to match when resolving modules. By default, this plugin looks...

I'm surprised this is so hard to get right. At its core, the situation is quite simple and looks common. We have a package `a` authored in CommonJS exposing a...

I've checked some scenarios with Rollup and Rollup seems to be doing something interesting. As long as the default export is a function, `require( "a" )` is a wrapper function:...

I tested Parcel with its experimental `exports` support enabled (https://parceljs.org/features/dependency-resolution/#enabling-package-exports) and there's no magic behavior for `require( "a" )` like in Rollup, it just returns `{__esModule: true, default: a}`. However,...

cc @devongovett for the Parcel case.

@GeoffreyBooth that's the issue - bundlers support passing an ESM version to `require` but then `require( "jquery" )` returns `{ default: jQuery, $: jQuery, jQuery: jQuery }` instead of `jQuery`...

> But that's my point: if you separate them, does it fix the issue for bundlers? I would assume those tools only bundle one version or the other, not both?...

@GeoffreyBooth are you proposing changes to the logic in bundlers or to jQuery? If the latter, could you elaborate your idea? I don’t see how wrapping a CommonJS file in...

Even if there was a condition only true for bundlers, it still wouldn’t help. What we need instead is a way to detect environments that support both `import` & `require`....