Range Error after upgrade to 2.1.1

[rakshans1]

numbro(4230).format({thousandSeparated: true})

Getting RangeError: toFixed() digits argument must be between 0 and 100 after webpack production build. Works without error in development mode.

I reverted version to 2.0.6 and everything works fine.

[klein141]

We encountered the same issue. Seems like it's working up to version 2.1.0

[BenjaminVanRyseghem]

Thanks for reporting this issue!

Does any of you have a clue on which release is causing this regression?

Thanks again!

[klein141]

Actually seems like the release from 3 days ago (2.1.2) is the one that introduces the issue. 2.1.1 is working for me.

[clonn]

after trying, version is 2.1.2, that make works well.

numbro(4230).format({average: true})

But when xxx is 0, that will make error happen.

numbro(xxx).format()

[kfei]

I also ran into this problem and I had to downgrade to 2.1.1 for it to work.

Stay tuned.

[devchris]

Are there any news on this? Is there a pr in the works?

[BenjaminVanRyseghem]

I haven't had time to investigate yet, but I will asap

[pwfcurry]

I have the same problem - this only occurs when creating a production build (via webpack) -- in dev, all is fine.

Note the old format "0,0" has the same problem.

Both 2.0.5 and 2.1.2 are affected.

The following function is getting called with a precision of -1 for some reason: https://github.com/BenjaminVanRyseghem/numbro/blob/develop/src/formatting.js#L463

function toFixed(value, precision) {
  if (value.toString().indexOf("e") !== -1) {
    return toFixedLarge(value, precision);
  }

  return (Math.round(+"".concat(value, "e+").concat(precision)) / Math.pow(10, precision)).toFixed(precision);
}

[handhikadj]

I have the same problem - this only occurs when creating a production build (via webpack) -- in dev, all is fine.

Note the old format "0,0" has the same problem.

Both 2.0.5 and 2.1.2 are affected.

The following function is getting called with a precision of -1 for some reason: https://github.com/BenjaminVanRyseghem/numbro/blob/develop/src/formatting.js#L463

function toFixed(value, precision) {
  if (value.toString().indexOf("e") !== -1) {
    return toFixedLarge(value, precision);
  }

  return (Math.round(+"".concat(value, "e+").concat(precision)) / Math.pow(10, precision)).toFixed(precision);
}

experiencing the same issue on latest vue.js

[BenjaminVanRyseghem]

Thanks for the input :smile:

[pwfcurry]

@BenjaminVanRyseghem By the way, I had no issues when running via react-scripts 1.0.14 (app was created with create-react-app) -- only had issues after upgrading to 2.1.5.

[pwfcurry]

The check here:

function setMantissaPrecision(output, value, optionalMantissa, precision, trim) {
  if (precision === -1) {
    return output;
  }

doesn't seem to work...

very odd.

[devchris]

Is there any estimate when this issue is going to be addressed?

[jansiegel]

Numbro 2.1.1 seems to work fine for me, but I get this error with 2.1.2 when using Webpack with mode: 'production', or by using the TerserPlugin (which is used by default in the production mode).

Switching to MinifyPlugin seems to fix the issue, so I guess the TerserPlugin does something in the minifying process, that messes up Numbro's logic.

[kylepeeler]

Bump, any update on this?

[denisgursky]

I have the same issue so change import to this

import numbro from "numbro/dist/numbro"

to make it work.

[freund17]

I ran into this issue as well...

I dug into it a little and - like @pwfcurry - I noticed, that the "-1 check" gets skipped for some reason. Turns out: For whatever reason this check gets removed from the production code. The reason you still see it in the debugger are the sourcemaps. Disabling sourcemaps reveals the truth. :P

I strongly suspect terser to be the culprit here. And judging from @jansiegel's comment and the number of upvotes that seems to be right...

Funnily: Using the non-minified build (as @denisgursky commented) does not trigger the removal.

I'm using: [email protected] [email protected] [email protected] [email protected]

[freund17]

EDIT: This theory turned out to be wrong. Terser is simply elevating the closure-variable. - Nothing wrong with that. I'm leaving the old comment for archive-reasons...

---

I can now confirm, that this is indeed a bug in terser.

Steps to reproduce:

1. Grab the /dist/numbro.min.js file
2. Execute npx [email protected] numbro.min.js --compress -o test.js
3. Search for function(e,t,r,n,i){if(-1 in numbro.min.js and test.js

In numbro.min.js you'll find:

function(e,t,r,n,i){if(-1===n)return e;

In test.js you'll find:

function(e,t,r,n,i){if(-1===S)return e;

Notice the n got changed to S. This probably makes the statement -1===S to always be falsy, which in turn flags it for code removal.

I tested a few terser-versions and all seem to have this problem. I created a ticket over there: https://github.com/terser-js/terser/issues/352

[freund17]

I'm back again. Pretty sure I found the problem this time around: https://github.com/terser-js/terser/issues/354

[Yonben]

Great job finding that @freund17 ! Really hope it will be fixed soon :)

[brendonboshell]

In the meantime, you can configure Terser to turn off the collapse_vars option. The webpack config will look something like this:

optimization: {
  minimizer: [
      new TerserPlugin({
        terserOptions: {
          compress: {
            collapse_vars: false
          }
        }
      })
    ]
}

[ryangiglio]

As of July 31st @freund17's patch on Terser was merged in https://github.com/terser/terser/issues/354#event-2522403250 and updating to 4.2.1 solved this problem for me

[jonathanrz]

I am still seeing this issue with 2.3.1 and 2.3.2

[madrogue]

This is most-likely the same issue we're seeing with this issue and the '0' and '0,0' formats, but not the '0.0' format.