big.js is a CommonJS dependency

[kbeelman]

Steps to reproduce:

1. Use npm to install big.js in an Angular 10+ library.
2. Import big.js into a file in the Angular library.
   In this case import Big from 'big.js';, import { Big } from 'big.js'; and import * as Big from 'big.js'; all behave the same.
3. Build the library.
4. Install the library in an Angular 10+ project and build that project.
5. Get the following error:
   WARNING in <PROJECT_DIRECTORY>\node_modules\<PARENT_PACKAGE>\__ivy_ngcc__\<PACKAGE_NAME>\fesm2015\<PROJECT_NAME>.js depends on 'big.js'. CommonJS or AMD dependencies can cause optimization bailouts. For more info see: https://angular.io/guide/build#configuring-commonjs-dependencies

It seems that the big.js package provided by npm doesn't properly export its ES Module. Upon looking into the package, I do see big.mjs, but any attempt at doing something like import Big from 'big.js\big.mjs'; causes a compilation failure.

[MikeMcl]

This seems like it's an issue with the Angular build/compilation process, but I am not familiar with Angular and so am unable to help.

From looking at this issue, try

import { Big } from 'big.js/big';

[imirkin]

Adding a "es2015": "big.mjs" line to package.json would fix it. The angular guys suggested using "exports", but I tried a bunch of things and couldn't get it to work (I'm a noob at all this though). @MikeMcl would you be open to adding such a line to the package.json? Looks like the angular build uses that in preference to "browser" (although webpack doesn't make a mention of it).

[MikeMcl]

https://nodejs.org/api/packages.html#packages_dual_commonjs_es_module_packages
https://webpack.js.org/guides/package-exports/
https://github.com/jkrems/proposal-pkg-exports/
https://www.sensedeep.com/blog/posts/2021/how-to-create-single-source-npm-module.html
https://gils-blog.tayar.org/posts/using-jsm-esm-in-nodejs-a-practical-guide-part-2/
https://blog.logrocket.com/es-modules-in-node-today/

@imirkin

Perhaps

// package.json
{
  "exports": {
    "import": "./big.mjs",
    "require": "./big.js"
  },
 // ...
}

or

// package.json
{
  "exports": {
    ".": {
      "import": "./big.mjs",
      "require": "./big.js"
    },
    "./package.json": "./package.json"
  },
 // ...
}

Though any use of the exports field prevents loading from subpaths of the package so it would probably cause issues for some users. (The main and module fields would still be required for typeScript, as it doesn't support the exports field.)

I want to support angular but I am not convinced that just adding an es2015 field is the right way to go.

Once you have done the research and analysed all the 'several "possible” solutions' and come up with a robust recommendation which works everywhere - typescript, webpack, rollup, node, browsers etc. - let me know.

[imirkin]

@MikeMcl yeah, I tried both of those exports settings in my random flailing, without success (I mean, it "worked", but Angular would pick the .js, which I could tell by looking at the final file that was produced). I just edited the package.json in node_modules, which I think should be sufficient.

Actually looking closer, I don't think I ever tried adding "./package.json" to the exports list.

Can I try also removing the "browser"/"module" entries? I'm concerned these are interfering with "exports".

But I also don't want to lead anyone on -- if you need a solution that's tested with all of those tools, I don't think I'll be able to provide it. I'm not familiar with those other tools, and don't have the time (or, frankly, the motivation) to learn how to operate them.

I can also keep using my workaround for now, which is convincing typescript to load the mjs with a path override as shown in the associated angular-cli issue.

[imirkin]

In part a note-to-self, but in the issue you just linked, you point out that

import {Big} from bla

and

import Big from bla

are actually not the same. And looking over the code-base, it does look like we got sloppy some of the time. I will retest those exports settings with that fixed up and see what happens.

[imirkin]

I don't know what I'm doing wrong, but even removing the "module" and "browser" settings (but leaving "main"), I can't get "exports" to work -- it still grabs the .js. (I'm using Node v14.17.5.) I'm doing import {Big} from "big.js"; everywhere. Sigh... I guess I'll stick to my workaround. I know it's hard to please everyone. Feel free to ping me if you'd like me to test something.

[MikeMcl]

@imirkin

For angular, I think just removing "browser" should work (with or without "exports"), because then it should use "module" which points to bignumber.mjs.

[imirkin]

@MikeMcl Yeah, that works of course. But I assumed that was a non-starter ... you added it because some people were complaining about getting the module... But perhaps further changes have gone in to normalize the situation?

[MikeMcl]

@imirkin

Yes, maybe "exports" will handle the tools that needed "browser".

[adamdport]

@MikeMcl am I correct that this has NOT been released yet? Looks like thiw as merged on May 19th and the latest 6.1.1 was published May 3rd? Is there a plan for another release?

[MikeMcl]

@adamdport

I am not clear what you mean.

Anyway, v6.2.1 is the latest release.

[adamdport]

@MikeMcl sorry about that. Not sure what I was looking at that showed 6.1.1 as the latest. Thank you!

[adamdport]

FWIW the warning still shows up for me after upgrading big.js and so I did some experimentation:

• Warning shows in Angular 11 when building a project with a library that uses big.js@6.1.1
• Warning shows in Angular 14 when building a project with a library that uses big.js@6.1.1
• Warning shows in Angular 11 when building a project with a library that uses big.js@6.2.1
• Warning DOES NOT show in Angular 14 when building a project with a library that uses big.js@6.2.1

I don't expect big.js to do the work of investigating this since upgrading Angular seems to resolve it, but thought I'd share my findings for anyone else that's debugging this