Tree Shaking

[jacobp100]

What are your thoughts on making all functions ES6 exports (like add etc), then providing a 'lite' constructor with no functions defined on the prototype or as static functions constructor? This would mean people could use the exported functions directly and can tree shake.

My project uses ReScript (/ReasonML), so I just write bindings to whatever the exports are.

In the app, the calculations are done in a web worker, so pretty much requires the whole of this library. However, once calculated, the results are sent back to the client, but the only functionality I need from this library is toString.

Having this library be tree-shakable would significantly reduce the size of my client file.

[jacobp100]

Thanks for the offer! I can handle doing this myself - I just wanted to know if you were interested in having it in the library. I'll aim make a copy of this library with the fix in the project I mentioned. You're welcome to copy it back if you want.

[jacobp100]

My work is over at https://github.com/jacobp100/technicalc-calculator/blob/master/decimal

Still in the process of getting all the tests to pass - but a few of the suites are passing already

I get a 15kb decrease minified. I noticed function names get minified now too. But also some of that reduction comes from reducing the precision of pi and ln10

[MikeMcl]

I'm committed to keeping this library ES3 compatible, but I'll take a look. It's a good idea.

[jacobp100]

Have you looked into adding build tools to this? It should be possible to write just one version (ES3 but with ES6 imports/exports), then produce an ES3-only bundle. That's something I could help with if you need!

[MikeMcl]

Yes, that has been considered, but at the moment I prefer to just include a separate ES module file, decimal.mjs.

[jakub791]

I'm committed to keeping this library ES3 compatible, but I'll take a look. It's a good idea.

ES5 is supported everywhere now, including Internet Explorer which is like 10 years old. You do not need to support anything below that. If someone's browser does not support ES5 (or even ES6 now) then that isn't our issuse.

[jakub791]

Yes, that has been considered, but at the moment I prefer to just include a separate ES module file, decimal.mjs.

Why does it use ES3 compatible syntax? Modules were added in ES6.

[WuglyakBolgoink]

Any updates?

[MikeMcl]

@WuglyakBolgoink

Yes, I have a bad cold and can't concentrate on anything.

[WuglyakBolgoink]

@WuglyakBolgoink

Yes, I have a bad cold and can't concentrate on anything.

get well soon!!!

[MickL]

Hey guys! I saw there is a light version of decimal.js and was thinking that this wouldnt be needed at all if decimal.js would support tree shaking properly. This could be done by using individual imported functions which would also have the benifit of this functions to be better testable because they have clear inputs and outputs:

Current code:

x = new Decimal(255.5)
x.toExponential(5)
x.toFixed(5)
x.toPrecision(5)

Possibly new syntax:

import { Decimal, toExponential, toFixed, toPrecision } from 'decimal.js';

x = new Decimal(255.5).pipe(
   toExponential(5),
   toFixed(5),
   toPrecision(5),
);

I assume this would result in lower bundles sizes as decimal.js-light offers for most cases.

P.S. Possibly with this refactoring decimal.js could switch to TypeScript and drop support for older ES versions :)

[josdejong]

an other option would be to change from methods into functions, like:

import { Decimal, add, subtract } from 'decimal.js'

const a = new Decimal("0.1")
const b = new Decimal("0.2") 
const c = add(a, b)
const d = subtract(a, b)

[MickL]

Yeah thats exactly what I meant :) Except possibly a pipe() function could be added to Decimal . Either way would be a nice solution.

[josdejong]

Ah, true, a pipe function can pipe those static functions like add(a, b)

[jacobp100]

@MickL I’d be sceptical of the pipe function for performance reasons. Not only do you need to allocate for the temporary function, if any arguments are floats, they’d also need to be boxed - so even more allocations. Direct function calls are much more efficient