Big is not a function

[mitra42]

I'm seeing a new bug

const Big = require('big.js')
...
Big(0)

fails with Big is not a function.
This is in a webpacked environment, it appears Big.Big(0) works, which combined with an update 10 hours ago that says it changed the exports, suggests the exports are not working with webpack.

[mitra42]

I can confirm that using package.json to go back to 5.0.3 works.

[MikeMcl]

I am assuming that for some reason your require('big.js') call is loading the big.mjs file, and that your environment has a problem with Big being exported in the file as a named export as well as the default export - Node.js doesn't have a problem with this.

I have removed the named export from big.mjs to 'fix' it in v5.1.1.

If that is not what caused the issue it must be the fact that I changed the main field in the package.json from 'big.js' to 'big', for better compatibility with modules.

[mitra42]

I'm not totally sure, I'm importing ipfs which imports ipfs-bitswap which is doing the require('big.js').

I don't know why webpack gets the big.mjs file (we are using webpack --mode development which does not itself minify). The problem seems to be that "const Big = require('big.js')" seems to set Big as a structure of some kind so Big(0) doesn't work.

[rahulgi]

Also using webpack. I'm importing big using import Big from "big.js". In the latest version, this gives the error Unhandled Rejection (TypeError): __WEBPACK_IMPORTED_MODULE_0_big_js___default.a is not a constructor when trying to do new Big(0). As @mitra42 said above, downgrading to 5.0.3 fixes the issue.

[MikeMcl]

Okay guys, let me know if the version I've just published works, v5.1.1.

If not, the problem must be with the change I made to the package.json, and I'll probably roll it back.

[rahulgi]

giving it a shot!

[rahulgi]

@MikeMcl still seeing the issue in v5.1.1.

[jacobheun]

@MikeMcl Adding "big.js" to the browser field, #97, resolves this if you don't want to rollback.

[MikeMcl]

I've published v5.1.2 with the browser field added and named export restored.
Please let me know if there are any further issues.

Memo:
I changed the main field of the package.json in v5.1.0 from "big.js" to "big" so that node --experimental-modules scripts load the big.mjs file instead of the big.js file. (Node doesn't use the module field).
In big.mjs, I added Big as a named export as well as the default export so that scripts could use import {Big} as well as import Big.

[tripodsan]

btw, I had the same issue with webpack, even with version 5.2.2. the solution was to change the module resolve order:

      resolve: {
        mainFields: ['main', 'module'],
        extensions: ['.wasm', '.js', '.mjs', '.json'],
      },

see:

• https://webpack.js.org/concepts/module-resolution/#module-paths
• https://webpack.js.org/configuration/resolve/#resolvemainfields
• https://webpack.js.org/configuration/resolve/#resolveextensions