Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider removing dependencies on 3rd party APIs for user settings #8584

Closed
thomasneirynck opened this issue Oct 7, 2016 · 4 comments
Closed
Labels
chore high hanging fruit stale Used to mark issues that were closed for being stale Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc

Comments

@thomasneirynck
Copy link
Contributor

thomasneirynck commented Oct 7, 2016

Kibana exposes several 3rd party APIs in the settings.

This has some long term maintenance challenges:

  • make removal/replacement difficult, as users may depend on quirks/extra features of the library
  • may cause breaking changes in Kibana when there are upstream changes.
@spalger
Copy link
Contributor

spalger commented Oct 10, 2016

Interesting replacement for numeral: https://github.com/foretagsplatsen/numbro

@thomasneirynck
Copy link
Contributor Author

From the discussion on 10/7.

  • The goal is not necessarily to ditch 3rd party library, but to document the supported functionality and take ownership of that public specification.
  • This should be considered a breaking change.
  • Can use numeral.js as a starting point

@spalger spalger removed the discuss label Oct 11, 2016
@epixa epixa added the Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc label Oct 29, 2016
@thomasneirynck
Copy link
Contributor Author

cf. #8983: request for feature specifically supported by numeral.js.

@marius-dr
Copy link
Member

I encountered another issue in the markdown library:
new lines are now treated differently as opposed to the Github markdown. They now require at least 2 spaces or a \ ending the first line in order for it to be rendered as a Hard Line Break. It's not really a big deal, but seeing as we reference the Github markdown documentation in there, we do have a different behavior than the one in there. Maybe we should be referencing the Commonmark spec that marked seems to be using?

@joshdover joshdover added the stale Used to mark issues that were closed for being stale label Jan 14, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
chore high hanging fruit stale Used to mark issues that were closed for being stale Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc
Projects
None yet
Development

No branches or pull requests

5 participants