Issue 1:
Where target: "web" is set inside Webpack, it defaults resolve.mainFields to be ["browser", "module", "main"].

I'm running into issues whereby certain libraries like https://github.com/krisk/fuse (amongst others) are not transpiling the code they reference via module. This means that where module is prioritised over main, certain cutting-edge features are making it into the bundle file, hence resulting in poor browser compatibility.

The argument can be made that libraries should transpile their module output by default whilst keeping ES Module support; however, this doesn't seem to be standardised, and to me it seems like an uphill battle to enforce our interpretation of a non-standard feature (there is no mention in any proposed spec of whether module can or cannot contain cutting-edge JavaScript).

Is this current method of prioritising the module field before main in all circumstances the most appropriate way to handle module resolution?

What is the best approach to ensuring maximum browser compatibility whilst reducing the amount of code to be transpiled during build processes, and preserving features such as tree-shaking?

I am considering a strategy similar to the following:

If browser exists on package.json, load this; if not,

If module exists on package.json and sideEffects is set to false, load this; if not,

If main exists on package.json, load this; if not,

If module exists on package.json, load this.

Any suggestions or thoughts on this issue are welcome! Thanks 😄

Issue 2:
Do you want to request a feature or report a bug?

bug

What is the current behavior?

module entry in package.json gets prioritised over the main entry (even on Node.js).

Consider deepmerge package: https://unpkg.com/deepmerge@1.5.2/dist/es.js

This:

...
export default deepmerge_1;

gets transpiled into:

/* 2043 */
/*!********************************************************************!*\
!*** /Users/donaldtrump/work/JITU/node_modules/deepmerge/dist/es.js ***!
\********************************************************************/
/*! exports provided: default */
/*! all exports used */
/***/ (function(module, __webpack_exports__, __webpack_require__) {
....

var deepmerge_1 = deepmerge;

/* harmony default export */ __webpack_exports__["default"] = (deepmerge_1);

/***/ }),

And therefore another module using it and not suspecting anything crashes:

https://unpkg.com/rest-facade@1.8.0/src/Client.js

var deepmerge = require('deepmerge');

this.options = deepmerge(defaultOptions, options || {}, true);

Because it naturally expects the plain and simple CommonJS export which is supposed to be a function.

Webpack tries to be overly smart in this case resulting in an incompatibility.

If the current behavior is a bug, please provide the steps to reproduce.

Create an application using rest-facade and it will throw "deepmerge is not a function" (because it's an object now for no reason).

What is the expected behavior?

Not throwing the aforementioned error

If this is a feature request, what is motivation or use case for changing the behavior?

Please mention other relevant information such as the browser version, Node.js version, webpack version and Operating System.