The metadata for the current kibana project install that is seeded to
the client-side app via window.__KBN__ is now accessible anywhere via
the immutable ui/metadata singleton. window.__KBN__ now becomes a tested
implementation detail of only a single module in the whole app, whereas
any consumer of the metadata now has an explicit module dependency and
has no way to modify the metadata contents.
Rather than having to maintain possible configuration values in two
different places, the "immutable field" logic is removed in favor of
defining readonly fields in the default config file.
The function is now unit tested as well. There are a few flags of the
resulting configuration object that are not yet tested, but they're
really behaviors of the returned value based on the current state rather
than behaviors of toEditableConfig itself.
If the kibana index includes any custom key/value pairs in the config,
they will be editable on the advanced settings panel. All custom
settings appear at the bottom of the list and are visually labeled as a
"custom setting". When the trash can icon is clicked, custom settings
are removed entirely from the index.
During build we transpile the server source to prevent runtime transpilation with babel/register. In order to support untranspiled plugin code, we still use babel/register with special ignore options, which used to be included in cli/index.js and now is moved to src/optimize/babelOptions.js so other code that wants to initialize a server (without the cli) can also configure babel/register.
Fixes#4866
As recently discussed in https://github.com/elastic/kibana/issues/4824 we have had a fair number of challenges with dependencies shipping breaking changes or broken code within the semver ranges which should prevent them. Nobody is perfect, we don't expect that, but as Kibana grows the number of modules does too. The output of npm ls is currently over 1100 lines, meaning we are very exposed to the semver ranges specified.
While we may actually use a shrinkwrap file at some point, or implement something like uber's custom shrinkwrap utility, the only issues we have faced have been caused by top level dependencies (especially the very fast-moving ones).