Internet Explorer problem as of version 3.0.17 (minor upgrade)

[nicohvi]

Hello, thanks for all the amazing work with this great library :)

We recently ran into a problem upgrading baconjs from 3.0.15 to 3.0.17 in the Internet Explorer browser (some of our users still use IE).

The error is due to an arrow function still being present in Bacon.mjs, which is automatically included by our babel-loader:

// line 21 in Bacon.m.js
/** @hidden */
function always(x) { return () => x; 

We can solve this problem by making an exception in our babel ruleset to transpile the bacon code as well as our application code, but we just wanted to ask if this is intended or a bug?

Anyway, thank you very much for the great library!

[semmel]

I think since v3.0.11 dist/Bacon.mjs is shipped with ES6 code; so all kinds of =>, class etc. which should all not work in IE11.

In v.3.0.17 I added the "module" and "exports" fields in package.json. Maybe that is picked up by the babel-loader?

[semmel]

For IE11 there is still the UMD version dist/Bacon.js.

The "exports" fields are to aide Node.js to load ES modules with bare import specifiers or self-referencing a package.

The "module" field should point Rollup or Webpack to the ES module. (See comment).

What would you suggest to make the package more babel-loader-friendly? I'd rather not go back and ship a larger ES5 code base to JS engines which are optimised for ES6.

[nicohvi]

I think the problem lies with webpack, since the module bundler assumes we want to import dist/Bacon.mjs rather than dist/Bacon.js (which might be a sensible default).

Reading their documentation on package exports it seems like the "exports" keyword in the package.json file is the cause of the issue, since the "exports" field for this package now specifies ./dist/Bacon.mjs explicitly.

I think the problem can be solved using the resolve.mainFields configuration, which can instruct webpack to look at "main" before "exports".