Option to exclude modules detected only by mainFields
LKay opened this issue · 3 comments
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!