Skip to content
This repository has been archived by the owner on Feb 12, 2024. It is now read-only.

Big is not a function error #1363

Closed
mitra42 opened this issue May 22, 2018 · 6 comments · Fixed by #1364
Closed

Big is not a function error #1363

mitra42 opened this issue May 22, 2018 · 6 comments · Fixed by #1364
Assignees
Labels
exp/novice Someone with a little familiarity can pick up kind/bug A bug in existing code (including security flaws) P0 Critical: Tackled by core team ASAP

Comments

@mitra42
Copy link

mitra42 commented May 22, 2018

  • Version: ipfs 0.28.2
  • Platform: Chrome, seeing this on webpack's done on:
    Linux wwwb-dev0.fnf.archive.org 4.4.0-45-generic fix - module not found #66-Ubuntu SMP Wed Oct 19 14:12:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux and on OSX
  • Subsystem: ipfs-bitswap

Type: Bug

Severity: Critical

Description:

After clearing out my node_modules to do a fresh install, I'm seeing a crash

Uncaught TypeError: Big is not a function
    at Stats.initialCounters.forEach (VM3189 stat.js:22)
    at Array.forEach (<anonymous>)
    at new Stats (VM3189 stat.js:21)
    at new Stats (VM3188 index.js:32)
    at new Bitswap (VM3157 index.js:48)
    at series (VM3156 start.js:41)
    at eval (VM2557 parallel.js:39)
    at eval (VM2555 once.js:12)
    at replenish (VM2569 eachOfLimit.js:61)
    at iterateeCallback (VM2569 eachOfLimit.js:50)

Steps to reproduce the error:

The rough build procerss was:

rm package-lock.json and npm_modules
npm install; 
webpack --mode development # of something that does a require('ipfs')

Its happening with my repo dweb-transports, and I don't currently have a workaround since this is deep in the IPFS code.

@mitra42
Copy link
Author

mitra42 commented May 22, 2018

Some investigation ....
ipfs-bitswap/src/stats/stat.js requires big.js and package.json has dependency on big.js "^5.0.3"
node_modules includes big.js
big.js is in node_modules v5.1.0 and does an export var Big

Running the Chrome debugger and pausing at this line I see ...

> Big
{default: ƒ, __esModule: true}Big: (...)default: ƒ Big(n)__esModule: trueget Big: ƒ ()__proto__: Object

but running the function

> Big(0)
VM6096:1 Uncaught TypeError: Big is not a function
    at eval (eval at Stats.initialCounters.forEach (stat.js:NaN), <anonymous>:1:1)
    at Stats.initialCounters.forEach (stat.js:22)
    at Array.forEach (<anonymous>)
    at new Stats (stat.js:21)
    at new Stats (index.js:32)
    at new Bitswap (index.js:48)
    at series (start.js:41)
    at eval (parallel.js:39)
    at eval (once.js:12)
    at replenish (eachOfLimit.js:61)

Which is a very strange debug trace ?

Almost as if Big is being redefined somewhere?

@mitra42
Copy link
Author

mitra42 commented May 22, 2018

More investigation ...
Immediately after defining in big.mjs its

>Big
ƒ Big(n) {

But after the requires its defined as the result of the require. Replacing the call in stats.js to Big(0) by Big.Big(0) works,

I notice on the big repository that it was changed 10 hours ago to change exports big.mjs so I'm guessing that is the problem.
See MikeMcl/big.js#95

@mitra42
Copy link
Author

mitra42 commented May 22, 2018

Workaround for now is to set in package.json : dependencies { "big.js": "5.0.3" }

Since the fix that broke this was today, the "Big" package might get fixed quickly, otherwise it may need to force that precise version in ipfs-bitswap and anywhere else its used.

@alanshaw
Copy link
Member

alanshaw commented May 23, 2018

It was apparently fixed in v5.1.1 but I'm still getting browser test failures locally even with it installed:

$ npm ls big.js
ipfs@0.28.2 /Users/alan/Code/protocol-labs/js-ipfs
├── big.js@5.1.1 
├─┬ interface-ipfs-core@0.65.9
│ └── big.js@5.1.1  deduped
├─┬ ipfs-api@21.0.0
│ └── big.js@5.1.1  deduped
├─┬ ipfs-bitswap@0.20.0
│ └── big.js@5.1.1  deduped
├─┬ ipfs-repo@0.20.0
│ └── big.js@5.1.1  deduped
├─┬ ipfsd-ctl@0.34.0
│ └─┬ ipfs-repo@0.19.0
│   └── big.js@5.1.1  deduped
├─┬ ipld@0.17.0
│ └─┬ ipfs-repo@0.19.0
│   └── big.js@5.1.1  deduped
├─┬ libp2p@0.20.4
│ └─┬ libp2p-switch@0.39.2
│   └── big.js@5.1.1  deduped
└─┬ transform-loader@0.2.4
  └─┬ loader-utils@1.1.0
    └── big.js@3.2.0 

alanshaw added a commit that referenced this issue May 24, 2018
Big.js just released an update that added esmodule support by adding a "module" field to their package.json. By default, webpack will use this field when requiring a module. Since esmodules aren't fully supported in the browser and we don't do any transpiling this PR configures webpack to not consider the esmodule field.

[Webpack `mainFields` docs](https://webpack.js.org/configuration/resolve/#resolve-mainfields)

[Why `require('big.js')` is broken for us](webpack/webpack#4742)

Fixes #1363

License: MIT
Signed-off-by: Alan Shaw <alan@tableflip.io>
@ghost ghost assigned alanshaw May 24, 2018
@ghost ghost added the status/in-progress In progress label May 24, 2018
@alanshaw
Copy link
Member

@mitra42 I just submitted a PR to fix this #1364

@alanshaw alanshaw added kind/bug A bug in existing code (including security flaws) exp/novice Someone with a little familiarity can pick up P0 Critical: Tackled by core team ASAP labels May 24, 2018
alanshaw added a commit to ipfs-inactive/js-ipfs-http-client that referenced this issue May 24, 2018
Big.js just released an update that added esmodule support by adding a "module" field to their package.json. By default, webpack will use this field when requiring a module. Since esmodules aren't fully supported in the browser and we don't do any transpiling this PR configures webpack to not consider the esmodule field.

[Webpack `mainFields` docs](https://webpack.js.org/configuration/resolve/#resolve-mainfields)

[Why `require('big.js')` is broken for us](webpack/webpack#4742)

Refs ipfs/js-ipfs#1363

Note that this solves the issue for `big.js`, but also for any other modules in the future that decide to define a `module` field in their `package.json` or any that already do and we just haven't realised it yet!

License: MIT
Signed-off-by: Alan Shaw <alan@tableflip.io>
@mitra42
Copy link
Author

mitra42 commented May 24, 2018

Thanks - looks like it worked.

@ghost ghost removed the status/in-progress In progress label May 28, 2018
daviddias pushed a commit that referenced this issue May 28, 2018
Big.js just released an update that added esmodule support by adding a "module" field to their package.json. By default, webpack will use this field when requiring a module. Since esmodules aren't fully supported in the browser and we don't do any transpiling this PR configures webpack to not consider the esmodule field.

[Webpack `mainFields` docs](https://webpack.js.org/configuration/resolve/#resolve-mainfields)

[Why `require('big.js')` is broken for us](webpack/webpack#4742)

Fixes #1363

License: MIT
Signed-off-by: Alan Shaw <alan@tableflip.io>
daviddias pushed a commit to ipfs-inactive/js-ipfs-http-client that referenced this issue May 29, 2018
Big.js just released an update that added esmodule support by adding a "module" field to their package.json. By default, webpack will use this field when requiring a module. Since esmodules aren't fully supported in the browser and we don't do any transpiling this PR configures webpack to not consider the esmodule field.

[Webpack `mainFields` docs](https://webpack.js.org/configuration/resolve/#resolve-mainfields)

[Why `require('big.js')` is broken for us](webpack/webpack#4742)

Refs ipfs/js-ipfs#1363

Note that this solves the issue for `big.js`, but also for any other modules in the future that decide to define a `module` field in their `package.json` or any that already do and we just haven't realised it yet!

License: MIT
Signed-off-by: Alan Shaw <alan@tableflip.io>
danieldaf pushed a commit to danieldaf/js-ipfs-api that referenced this issue Jul 21, 2018
Big.js just released an update that added esmodule support by adding a "module" field to their package.json. By default, webpack will use this field when requiring a module. Since esmodules aren't fully supported in the browser and we don't do any transpiling this PR configures webpack to not consider the esmodule field.

[Webpack `mainFields` docs](https://webpack.js.org/configuration/resolve/#resolve-mainfields)

[Why `require('big.js')` is broken for us](webpack/webpack#4742)

Refs ipfs/js-ipfs#1363

Note that this solves the issue for `big.js`, but also for any other modules in the future that decide to define a `module` field in their `package.json` or any that already do and we just haven't realised it yet!

License: MIT
Signed-off-by: Alan Shaw <alan@tableflip.io>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
exp/novice Someone with a little familiarity can pick up kind/bug A bug in existing code (including security flaws) P0 Critical: Tackled by core team ASAP
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants