Julien Sanchez

@mikberg the easy solution would be to expose the internal unit definition object for maximum usage flexibility but it would be a bad idea to let client code to mess...

It's OK to group names since it keeps some useful information. If needed, it will be up to client code to flatten/sort or anything else with returned lists.

Thank you @mikberg for the PR. Two remarks however: I prefer you keep your previous `getPrefixes()` and `getKinds()` methods. It would be cleaner and more logical than `getUnits("prefix")` (`getUnits()` should...

Yes, UCUM compatibility is definitely a goal for the library. I thought about it a long time ago... It would be great to check if there are incompatibilities with the...

Unfortunately, I currently have 2 objections to this proposal : * First, a `pH` unit would conflict with the unit picoHenry of the electrical inductance (`3 pH`)) * Second, `pH`...

Thanks for your feedback @carlo-quinonez. I am not opposed to include `pH` as a concentration measure (it will just have to be documented somewhere in the library). Perhaps we could...

How would you differentiate units between gal (US Gallon currently in the library) and Imperial Gallon?

You just came across a parsing bug with `%`. I will try to fix it shortly. It's far from ideal but you could replace `%` with `percent` if it is...

Could you check your example? I just tried and it outputted `44ml` as expected: ``` javascript Qty('3tbs').to('ml').toPrec('ml').toString(); // => "44 ml" ``` There's also a typo in your example: `tb`...

According to several references, there's `14.7867648 ml` in a tb (so approximately `44ml` for three tb): ``` javascript Qty('1 tbs').to('ml').toString(); // => "14.7867648 ml" Qty('3 tbs').to('ml').toString(); // => "44.3602944 ml"...