Custom units

[jnawk]

Feature request: Ability to define custom units
If this is already possible, some documentation on how to do so would be super.

[jonahsnider]

Custom units would be a useful feature to have.

I'd probably implement this by having some kind of API to create an instance of a Converter class which lets you register custom units at runtime somehow. With the current way Convert is written this would be a bit of a hassle to add since all the current code uses the one big lookup table for conversion ratios.

I'm pretty busy these days so unfortunately I can't make any guarantees on when I'll have time to add this feature.

[michaelessiet]

Any update on this?

[akshay-nm]

I ended up saving custom units in DB as I had such requirement.
type CustomUnit = { name: string; conversionFactor: number; baseUnit: string; measurementType: string }

So if a bag is 50kg
My custom unit looks like:
{ name: 'bag', conversionFactor: 50, baseUnit: 'kg', measurementType: 'mass' }

to convert to grams, I can do:
convert(customUnit.conversionFactor * value, customUnit.baseUnit).to(targetUnit)

[akshay-nm]

still can't support custom scales

[gwennlbh]

also interested in this, i might come up with an implementation idea and propose it

[ilyichv]

@jonahsnider hey! We’re running into a similar need on our side.

I’d like to define custom “best” units for certain measurements. For example, in my case L (liters) wouldn’t be considered the most appropriate default. Having access to the underlying class (or a way to override the best-unit logic) would be extremely powerful and flexible.

Would you consider starting a discussion about this on GitHub? Maybe you’ve already explored some ideas around it 🙂

[jonahsnider]

This issue has been super stale for years, mostly because I really couldn't find a way to implement this behavior without sacrificing type safety, runtime performance, or bundle size. I'm much more open to exploring this now, it's clear there's demand for this functionality in the library.

Likely a change like this would require some fairly involved refactors of Convert's internals. Unfortunately, I'm very busy lately, so I'm not sure when I'll actually have a chance to work through that.

[ilyichv]

This issue has been super stale for years, mostly because I really couldn't find a way to implement this behavior without sacrificing type safety, runtime performance, or bundle size. I'm much more open to exploring this now, it's clear there's demand for this functionality in the library.

Likely a change like this would require some fairly involved refactors of Convert's internals. Unfortunately, I'm very busy lately, so I'm not sure when I'll actually have a chance to work through that.

Yeah, I don’t think the class approach will work as it is. If I get some spare time over the next few weeks, I’ll try to take another look at it.

One idea that just crossed my mind is generating the files somewhere within the user’s project, but I haven’t tried it yet, so I’d need to test it first.