scurker / currency.js Goto Github PK

Option to specify grouping/numbering system.

Please refer: https://en.wikipedia.org/wiki/Indian_numbering_system

Consider adding a valueOf() method, to complement the current toString() method, which would return the numeric value of the currency.

Currently when comparing two currencies, they compare alphabetically (because toString() is used):

currency(20.00) > currency(10000) === true

When in fact they should be compared numerically (and the above would be === false).

Adding .valueOf() (which would just return .value) would allow for such situation.

Test: currency('1312.444445', {precision: 2})
Expected: 1312.45
Got: 1312.44

Test: currency(1312.45, {precision: 0})
Expected: 1313
Got: 1313

Test: currency('1312.45', {precision: 0})
Expected: 1313
Got: 1312

Only the second test yields a correct result! Then if I just pass the value as string instead of a number, the result is wrong!

installed from npm and this package is a empty package only include these files

Some currencies in common usage need some rounding. E.g. CHF when used for billing needs to be rounded to the next 0.05 value

• 1.342 => 1.35
• 1.3216 => 1.30

Add option to format or additional method .round to library

Need to set position of currency symbol (prefix/suffix). It depends on currency or country.

Example the number is '2.443233038698408e+21' and what currency.js does when currency('2.443233038698408e+21').format() the result is '2.44', that's not the correct answer!

Yarn yarn install --save currency.js

error install has been replaced with add to add new dependencies. Run yarn add currency.js instead.

  "main": [
    "dist/currency.js"
  ],

but dist-folder is missing

I modified your unit test should default rounding when parsing to use var round1 = currency(1.2349) instead of current 1.234 and that caused rouding to break (not half-up).

As reported by @iamjochem, formatting doesn't work correctly if you try to change the formatting values to non us-centric values (/pull/5).

currency.settings.seperator  = '.';
currency.settings.decimal    = ',';

currency(1000000.00).format();
// should return "1.000.000,00" but actually returns "1,000.000.00"

Right now, it's replacing the first decimal that matches, which causes issues if one of the settings values is a decimal.

In the arithmetic methods, allow another currency object to be passed, similar to moment.js.

Current solution is to currObj.add(anotherCurrObj.value)

Sorry I hadn't spotted them. Nice library :)

Version 3.4.0 of mocha just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As mocha is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

You've got an option seperater for specifying the string that should separate groups of numbers (i.e. ,). That's spelled incorrectly, and should instead be separator.

I'd be happy to submit a PR with this change. Would you like to leave the old option around without documentation for compatibility reasons?

Running this with typescript 2.4.2 and getting the following error: error TS2649: Cannot augment module 'currency' with value exports because it resolves to a non-module entity.

When using browserify/webpack inside a browser environment, with the immediately invoked function global will always point to window and never attach currency to module.exports correctly.

Looks like travis has a new infrastructure that I can start to utilize for builds. Just need to upgrade the travis.yml file to adapt to the changes. Should be able to leverage caching as well.

I received the following results when using precision of 18 or greater.

This is obviously an extreme example which would be unlikely to cause problems in most real life scenarios, but it is a bug nonetheless.

my code:

this.settlement.total = currency(this.settlement.amount, {precision: 18}).multiply((currency(1, {precision: 18}).add((currency(this.settlement.feePercent, {precision: 18}).divide(100))))).value;

Currently, currency.js does not handle integer values beyond the max/min possible int values. So for whatever reason if you're performing calculations in that range you could have some overflow errors.

The maximum possible value should be 2⁵³ - 1 or 9,007,199,254,740,991. There should probably be some tests around this, and the library could potentially throw an error if that number overflows. There's some additional functions available as part of the ES6 harmony draft that might be available to be used.

The devDependency html-minifier was updated from 3.5.20 to 3.5.21.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

html-minifier is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Not all currencies have two digits after the decimals. Some have 4 digits after the decimal, some have 0 digits after the decimal, while the majority have 2 digits after the decimal.

It would be nice to have an option for the constructor top specify the precision either as a method, or during creation:

currency(2.51)  // 2.51
currency(2.51, 4)  // 2.5100, with precision option

or

currency.settings.precision(4)

Although this would change the "global" settings for all currency instances after required. It would be nice to set the formatting, decimal, separator, symbol and precision on a per usage basis (I have a site that needs to work in multiple currency formats in NodeJS, and altering the settings currently affects everything)

Many suggest that currencies be stored with 4 digits after the decimal in databases (along with the currency code in use), so maybe switching from 2 digits in the internal native format to 4 digits might also be an option.

http://nginx.org/en/docs/http/ngx_http_v2_module.html

Currently only CommonJS is supported, and when fixing #24 it shouldn't be too difficult to add AMD support as well.

When I do something like

JSON.stringify({ value: currency(1234.56) })

The result comes back as "{"value":{"value":123456}}"

The issue is that the toString() method on the currency object is not getting called.

The documentation on scurker.github.io/currency.js needs to be updated to include all the changes made for v1.

The current docs on gh-pages branch are slightly outdated. It would be better to move to /docs to help to remain in sync with the main repo.

Separator does not show up when precision value is set to 0.

currency("2573693.75755", { precision: 4 }).format();   //  2,573,693.7,576

The output is 2,573,693.7,576
For me it should be 2,573,693.7576
No separator in decimal.

Similar to #36, it would be nice to have Flow definitions for currency.js.

I'm not sure exactly how to implement the flow definition, but the typescript definition could be used for inspiration.

I'd like to be able to create a currency object with a value that is in cents instead of dollars.

Example:

const amount = currency(500, { denomination: 'cents' }) // $5.00, not $500.00

See #35 for a large part of the discussion, but it would be nice to have Typescript bindings so that when using currency you can infer proper usage of properties and functions.

Right now, there's two ways to set the separator when formatting currency values. Both currency.settings.seperator and currency.settings.separator. The former should be removed in favor of the second, which will cause a breaking change for anyone that potentially updates to the newer version.

See npm/marky-markdown#55 for more details. Namely the superscript isn't being displayed correctly on npm.

Currently everything in the package is included for npm. Need to whitelist currency.js and currency.min.js to reduce the size in npm.

Instead of including closure compile as an internal library dependency, we can now use chadkillingsworth/closure-compiler-npm.

My code :
currency(1.23352,{precision:5}).multiply(4).add(3).value

output : 4937.08

Totally wrong (last version on last FF and windows 10)

Link to #9

There's no bower package config currently, and this is needed in order to work with bower.

During the upgrade to Babel 7, it seems that AVA is no longer picking up config/rename-internal babel plugin. I don't know if this is an issue with Babel 7, or AVA but I switched to testing the dist/currency.min.js version.

The current downside is you have to always run the build step before coverage & test.

I have price product:
currency(product.price, { separator: ' ' }).format()
It return:
770 606.00
When I using .dollars()
It return price but dont have separator
770606
Please help me. Thank you.

Great lib 👍
It would be even better if supporting abbreviation in future.

For example:
1000 -> 1k
1,000,000 -> 1m
etc

Hi,

It seems that rounding with option precision does not works correctly in some case:

• currency(0.43499, { precision: 2 }) => 0.44, but 0.43 is expected
• currency(1.354999, { precision: 2 }) => 1.36, but 1.35 is expected

When multiplying two numbers with different precision the rounded value is not the right one in the following case : XX.X55 with precision 2. The value returned is XX.X5 instead of XX.X6.

Here is an example:

var taxVal = currency(0.09975, {precision: 5}) 
// {intValue: 9975, value: 0.09975, s: {…}, p: 100000}

var amount = currency(180)
// {intValue: 18000, value: 180, s: {…}, p: 100}


amount.multiply(taxVal)
// {intValue: 1795, value: 17.95, s: {…}, p: 100}

The expected value would be 1796 with Banker's Rounding.

Is this the expected rounding behavior?

v1.0.2 (#78) or v1.0.3 did not publish correctly after pushing to Travis. The build successfully compiles, but it seems during the deployment step npm-run-all fails to run.

It would be useful if you included an explanation of the .value and .intValue properties on the home README.md page. The .value property is an important one as it makes your library able to seamlessly replace js floating point arithmetic, using two js numbers to produce another js number without the bugs of IEEE754

let test = currency(344).distribute(4) returning the array of object now, instead of array of values. Earlier it used to return the array of values. Is this correct behavior??

let CHY = value => currency(value, {precision: 2})
let result = CHY(99999747361065.39).format()
expected : 99,999,747,361,065.39
actual: 99,999,747,361,065.41

I import this package like this:

import currency from 'currency.js';
currency(1).add(1.1);

This code work fine on webpack build, but fail on node TypeError: currency_js_1.default is not a function. I use currency.js in TypeScript project.

The npm package source exports is module.exports = currency, which should be export = currency; in d.ts file. So, I think maybe we should modify the currency.d.ts , or build result.

When formatting a negative number with formatWithSymbol:true, the minus sign is placed after the currency symbol, i.e. "$-10.00". I think it's more commonly seen placed before the currency symbol, i.e. "-$10.00". Can this be changed, or at least an option added to choose where the minus sign should be placed?

When using the divide function as in currency(110).divide(currency(20)) the result should not be a currency. The result should be a string or a number. $110/$20 for example is 5.5, not $5.50.