## Summary This PR is part of the Kibana Sustainable Architecture effort. The goal is to start categorising Kibana packages into _generic platform_ (`group: "platform"`) vs _solution-specific_. ``` group?: 'search' | 'security' | 'observability' | 'platform' visibility?: 'private' | 'shared' ``` Uncategorised modules are considered to be `group: 'common', visibility: 'shared'` by default. We want to prevent code from solution A to depend on code from solution B. Thus, the rules are pretty simple: * Modules can only depend on: * Modules in the same group * OR modules with 'shared' visibility * Modules in `'observability', 'security', 'search'` groups are mandatorily `visibility: "private"`. Long term, the goal is to re-organise packages into dedicated folders, e.g.: ``` x-pack/platform/plugins/private x-pack/observability/packages ``` For this first wave, we have categorised packages that seem "straightforward": * Any packages that have: * at least one dependant module * all dependants belong to the same group * Categorise all Core packages: * `@kbn/core-...-internal` => _platform/private_ * everything else => _platform/shared_ * Categorise as _platform/shared_ those packages that: * Have at least one dependant in the _platform_ group. * Don't have any `devOnly: true` dependants. ### What we ask from you, as CODEOWNERS of the _package manifests_, is that you confirm that the categorisation is correct: * `group: "platform", visibility: "private"` if it's a package that should only be used from platform code, not from any solution code. It will be loaded systematically in all serverless flavors, but solution plugins and packages won't be able to `import` from it. * `group: "platform", visibility: "shared"` if it's a package that can be consumed by both platform and solutions code. It will be loaded systematically in all serverless flavors, and anybody can import / use code from it. * `group: "observability" | "security" | "search", visibility: "private"` if it's a package that is intented to be used exclusively from a given solution. It won't be accessible nor loaded from other solutions nor platform code. Please refer to [#kibana-sustainable-architecture](https://elastic.slack.com/archives/C07TCKTA22E) for any related questions. --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> |
||
---|---|---|
.. | ||
docs | ||
src | ||
test | ||
index.d.ts | ||
jest.config.js | ||
kibana.jsonc | ||
package.json | ||
README.md | ||
tsconfig.json |
kbn-tinymath
kbn-tinymath is a tiny arithmetic and function evaluator for simple numbers and arrays. Named properties can be accessed from an optional scope parameter.
It's available as an expression function called math
in Canvas, and the grammar/AST structure is available
for use by Kibana plugins that want to use math.
See Function Documentation for details on built-in functions available in Tinymath.
const { evaluate } = require('@kbn/tinymath');
// Simple math
evaluate('10 + 20'); // 30
evaluate('round(3.141592)') // 3
// Named properties
evaluate('foo + 20', {foo: 5}); // 25
// Arrays
evaluate('bar + 20', {bar: [1, 2, 3]}); // [21, 22, 23]
evaluate('bar + baz', {bar: [1, 2, 3], baz: [4, 5, 6]}); // [5, 7, 9]
evaluate('multiply(bar, baz) / 10', {bar: [1, 2, 3], baz: [4, 5, 6]}); // [0.4, 1, 1.8]
Adding Functions
Functions can be injected, and built in function overwritten, via the 3rd argument to evaluate
:
const { evaluate } = require('@kbn/tinymath');
evaluate('plustwo(foo)', {foo: 5}, {
plustwo: function(a) {
return a + 2;
}
}); // 7
Parsing
You can get to the parsed AST by importing parse
const { parse } = require('@kbn/tinymath');
parse('1 + random()')
/*
{
"name": "add",
"args": [
1,
{
"name": "random",
"args": []
}
]
}
*/
Notes
- Floating point operations have the normal Javascript limitations
Building kbn-tinymath
This package is rebuilt when running yarn kbn bootstrap
, but can also be build directly
using yarn build
from the packages/kbn-tinymath
directory.
Running tests
To test @kbn/tinymath
from Kibana, run node scripts/jest --config packages/kbn-tinymath/jest.config.js
from
the top level of Kibana.
To test grammar changes it is required to run a build task before the test suite.