Move Unit.js into a standalone npm library

[josdejong]

Just floating an idea here: the Unit.js class is a powerful piece of functionality on it's own, separate from math.js. It could be interesting to think about splitting it from math.js into it's own npm library, similar to the libraries Decimal.js, Fraction.js and Complex.js used by mathjs under the hood. Of course Unit.js should keep it's injection of methods like add, multiply, Complex, etc to keep it flexible and integrable).

What would we gain with it?

• Modularity. People may not need mathjs but just need to do some calculations with units.
• Focus. Moving it into a separate library can help focusing. Unit.js has it's own share of complicated problems, and being a part of a larger library (mathjs) doesn't make it easier I think.

@ericman314 do you have some thoughts in this respect?

[ericman314]

Sounds like a great idea. Not sure how difficult it would be. I'll give it some thought.

[harrysarson]

We could nab the @mathjs namespace on npm for it?

[josdejong]

@harrysarson I guess we could, though I think it will be more powerful if Unit.js would become a really standalone library, and not sort of a child project still coupled to mathjs.

[ericman314]

Sounds like a real challenge, but it feels like the right direction to take it. Where do we go from here? Do we create a new repo?

[josdejong]

I think it involves the following steps:

1. Create a proof of concept, get a clear view on the challenges
2. Find someone who likes to pick up this challenge and becomes the "owner" of the project. Since large part of the code was developed by @ericman314 it would make sense to me if it becomes his library, but it totally depends on if you, Eric, like it and feel like you have enough time to create and maintain the library.
3. Decide upon a name for the library, create an empty git repo and claim the name on npm.
4. Think about an API for the library:
   • Creation of units: class new Unit(...) or factory function unit(...)?
   • Dependency injection for the functions like add, multiply, ...
   • Configuration
   • Functions as methods like new x.add(b) or standalone functions like add(a, b) ? Functions as methods, like Decimal.js, Complex.js, and Fraction.js do, have as advantage a nice chaining API. The disadvantage though is that you can't do tree shaking, you have to bundle the complete class with all methods even if you just use a few.
5. Migrate and implement the new library. Functions, docs, examples, unit tests, ...
6. Start using the new library in mathjs

[harrysarson]

I like the idea of making mathjs into a monorepl with one github repo containing multiple npm packages. Although this approach has downsides too.

[josdejong]

Yes, it's also possible to spin multiple npm packages from the current mono repo.

The reason I'm interested in separating Unit.js is that, like say Decimal.js, it becomes even more powerful if it's focused and standalone. Having a mono-repo typically results in the units of functionality becoming entangled. It is harder to make the "right" decisions for Unit.js when the library when it is a small gear in a big clockwork. Putting it as a separate library can open up a whole new world of opportunities, just like mathjs did when I did split it from the Math Notepad UI.

I see the future of mathjs as being an integrated environment for mathematics in JavaScript: a "hub" merging a lot of different data types together (matrices, units, complex number, ...), and an expression parser making it convenient to work with mathematics in JavaScript. So, moving Unit.js (and also the Matrix classes) out of mathjs would help mathjs getting more focused, and will probably lead to an API that also makes it easier to extend mathjs with more data types (like typed arrays).

[harrysarson]

That makes a lot of sense 👍

[ericman314]

Sure, I'll take ownership. Sounds like a fun adventure. That part I'm unsure how to do would be injecting other types like Complex and Decimal into the new units module.

[josdejong]

Cool Eric 😎

There is no need to know all answers beforehand already, one step at a time.

Have a look at the Unit.js file in the modular_architecture branch, I think the new injection mechanism is much cleaner, can give some inspiration on how we could solve it for the new Unit.js library.

[ericman314]

All finished: https://github.com/ericman314/unitmath

Just kidding, all it does is output Hello, World!

[ericman314]

I just checked out the dependency mechanism in the modular_architecture branch. It looks great! It kind of reminds me of Angular's dependency injection. However, with unitmath I would like to try and follow the mantra of "do one thing and do it well." Math.js's strength is in managing dependencies and bringing all the different libraries together. I really would not want to have to repeat that mechanism with unitmath, as 99% of use cases in which unitmath will be used alone would not require dependencies on Fraction, Decimal, Complex, etc. I wouldn't want to bundle all of that extra code when it would rarely be used.

Instead, perhaps it would be enough to just allow users (and math.js) to override unitmath's internal add, multiply, round, etc., in order to support different types. unitmath would handle everything with the units, but the user would supply his own types and arithmetic methods for those types. A user's overriding methods could then perform operations between different types using type checking. Do you think that amount of flexibility would be enough for math.js to work with?