AndersDJohnson/webpack-babel-env-deps

Option to exclude modules detected only by mainFields

LKay opened this issue · 3 comments

LKay commented

The parameter mainFields should also take boolean false parameter which would disable modules that were detected only by presence of fields such as module or jsnext:main in the package.json.

Many libraries are shipped with both commonjs and es6 builds and thus have these parameters present in package.json. In most cases bundler such as webpack or rollup will pick up proper version of the module and process the source code, so there is no need to additionally transpile it.

By default the packages should be selected only by engines settings in package.json.

@LKay Thanks for filing this issue!

From what I can tell, webpack by default will use a module or jsnext:main field in preference to main in package.json if either are defined (see docs https://webpack.js.org/configuration/resolve/#resolvemainfields).

I understand that many packages may be published as partially transpiled so that the only unsupported feature is the ES modules syntax (e.g., with Babel + Rollup). In those cases, additional Babel transpilation may not be needed since Webpack itself understands ESM syntax. However, this module/jsnext:main bundle may have only Babel transpiled down to a higher version of Node or browser than your package supports, so checking engines is still a good idea.

I think the reason I assumed any module/jsnext:main package should be transpiled is that it could be ambiguous whether engines indicates the level of transpilation for main, for module/jsnext:main, or both (see this write-up from the Rollup author). If it's meant to mean both, then your idea works. If it's only meant to mean main, then we don't have enough information to assume it's safe not to transpile module/jsnext:main.

But according to Rollup:

pkg.module will point to a module that has ES2015 module syntax but otherwise only syntax features that the target environments support.

So I guess if we assume all package authors obey this rule, it's safe to implement support for this feature, at least for module packages?

@LKay Released in 1.6.0 1.6.1. Please let me know whether it works as expected for you. Thanks!

Hey @LKay, please try 1.6.1 actually since there was a bug with 1.6.0. Thanks!