Kibana: Remove external dependency on Numeral.js

[thomasneirynck]

We currently rely on numeral.js for number formatting (http://numeraljs.com/) and expose their pattern syntax to users in the field formatter settings

Remove this explicit external dependency. This would mean:

• we explicitly document the pattern syntax API supported by Kibana
• we maintain a test suite for it

This does not mean we need to remove numeral.js as an internal dependency, just that we take ownership of the pattern syntax.

See comments by @epixa here https://github.com/elastic/kibana/issues/8565#issuecomment-252271158.

[nfarrell]

Just to add to this, the NumeralJS lib seems to be stale,

• Last commit 18 months ago
• 104 open pull requests

With how deeply NumeralJS is integrated into Kibana now, there's going to be a lot more effort than before in adding "en-ie" (Ireland, Euro) as an option and setting its value.

It's not a showstopper, just added effort for us.

[elasticmachine]

Pinging @elastic/kibana-app

[wylieconlon]

I've done a lot of work to see if it's possible to replace numeral with Intl.NumberFormat, and the short answer is that it's blocked until 8.0 for various reasons. https://github.com/elastic/kibana/pull/53972

The short-term approach that I am taking instead is like you are suggesting here, to provide interfaces that express the same configuration as numeral, but in a way that doesn't depend on the library and can be changed later. So for example, the configuration { id: 'percent', minDecimals: 3 } might translate to the numeral pattern 0,0.000% but is also doable using Intl.NumberFormat({ style: 'percent', minimumFractionDigits: 3 }).

I have started implementing this in Lens in this future-facing way, but I think it's time to start discussing the deprecation plan for other apps. https://github.com/elastic/kibana/pull/56253

[elasticmachine]

Pinging @elastic/kibana-app-arch (Team:AppArch)

[wylieconlon]

Numeral.js patterns are a useful and concise abstraction, and the fact that we have been asking users to type them for years shows this. But Numeral has bugs and limitations, and it's time for us to go beyond. This comment will summarize the current state of things and talk about a plan.

Useful features of Numeral

• Some users have become familiar with the syntax
• Has the ability to choose decimal places, significant digits, scientific/accounting display
• Bytes formatting scales the magnitude automatically

Limitations of Numeral

• Discovering the right pattern is not easy
• Currency is not based on Locale https://github.com/elastic/kibana/issues/25993
  
  
  
  • We should support many currencies
  
  
• Bytes formatting is non-standard https://github.com/elastic/kibana/issues/7543
• Does not support leading zeroes https://github.com/elastic/kibana/issues/18625
• Does not display small numbers https://github.com/elastic/kibana/issues/5811
• Locales are incomplete https://github.com/elastic/kibana/issues/54351

What needs to change?

a. @elastic/kibana-app-arch now owns field formatters and should take over maintenance.
b. The way Kibana uses numeral is not like a standalone library. We should move it into kibana/packages.
c. Because the way we use numeral is custom, we need to write Kibana documentation for formatting that we support. We should stop linking to 3rd-party docs. https://github.com/elastic/numeral-js/issues/16
d. Backwards compatible pattern API, forward-facing API. This is how another Numeral fork did it, Numbro

Other related issue: https://github.com/elastic/kibana/issues/39211