feat: add module.exports named export for require(esm) compatibility - #700

Description

This makes it possible to use v4+ in CJS-contexts with require(esm) without any downstream code changes, by adding a special named export that require(esm) will favor instead of the usual { __esModule: true, default: ... } result.

Linked Issues

Relates to #661

Additional context

Because of how ESM works compared to CJS, by default require(esm) results in an object with the default export mapped to a default property rather than returning the default directly in order to allow access to named exports.

This means that while technically we can now use ESM-only packages in CJS contexts, because require is usually expected to be equivalent to importing the default it's not quite a "drop-in" because the require'er needs to account for the ESM/CJS interop to actually get that default value.

To account for this, require(esm) has a preference for a module.exports export which it will return if found, allowing upstream packages to explicitly define that named export to enable "drop-in" usage; this comes at the cost of preventing access to other named exports, but there are multiple easy ways to handle that including ensuring those properties are available on the module.exports value and/or making the named exports available via another file - I also don't think it's likely that these packages specifically will ever have named exports (even if there were some utilities or such, I'd expect they'd end up in a dedicated package since this is a monorepo).

Also see:

• https://nodejs.org/api/modules.html#loading-ecmascript-modules-using-require
• module: support 'module.exports' interop export name in require(esm) nodejs/node#54563

And as a fun little side fact, this code is actually pretty close to what rollup generates anyway:

var index = Object.assign(plugin, { configs });

export { index as default };