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 #8565 (comment).

[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. #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. #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 Add a currency field formatter #25993
  • We should support many currencies
• Bytes formatting is non-standard Bytes field format uses binary units while showing decimal unit labels #7543
• Does not support leading zeroes Support leading zeros in number field formatter #18625
• Does not display small numbers Support scientific notation for very small numbers #5811
• Locales are incomplete Add Norwegian locale for number formatters #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. elastic/numeral-js#16
d. Backwards compatible pattern API, forward-facing API. This is how another Numeral fork did it, Numbro

Other related issue: #39211

[wylieconlon]

Just as an update, we've done 3/4 of the steps above. The remaining step is to define a future APi, and I've made a proposal in this comment

[VijayDoshi]

@lukeelmers, is there work still happening on this?

[lukeelmers]

@VijayDoshi Nothing happening on the core side, but @Dosant on app services was tracking this work in a meta issue here: #102239

He or @ppisljar @petrklapka may know more about how it is currently being prioritized

[ppisljar]

we are not working on this at the moment due to other priorities

[elasticmachine]

Pinging @elastic/kibana-data-discovery (Team:DataDiscovery)

[kertal]

We are closing this issue in order to provide better transparency of priorities. This issue won't be prioritized in the near future. We track it in #163011 for long term planning.