Expression typings: Canvas to OSS

[lukeelmers]

Note: This PR replaces #36960, which I had to close after a botched merge. 🙄

Summary

Moves the Canvas Expression Function types that Clint worked on over to OSS so they can be exported from the interpreter for use by other plugins.

Usage / Testing

import { ExpressionFunction } from 'plugins/interpreter';
// ^^ From x-pack this currently needs to be done via absolute import, unfortunately:
// import { ExpressionFunction } from 'src/legacy/core_plugins/interpreter/public';

const name = 'myfunc';

interface Context {
  type: 'whatever'; // in most cases you'll be importing Context from elsewhere
}

interface Arguments {
  foo: boolean | null;
}

interface Return {
  type: 'whatever'; // in most cases you'll be importing Return from elsewhere
}

export const myfunc = (): ExpressionFunction<typeof name, Context, Arguments, Return> => ({
  // function definition
});

[lukeelmers]

@clintandrewhall @ppisljar @chrisdavies Sorry fellas, I did something strange in my merge on the original PR so had to open this new one. Nothing has changed so far other than a few updates to address the feedback from Clint.

Feel free to chime in with anything else that's missing. We have both been looking at Clint's testing branch #37300 and trying to sort out the CI issues there... seems to have to do with failed module imports and (hopefully) nothing to do with the implementation itself.

[elasticmachine]

Pinging @elastic/kibana-canvas

[elasticmachine]

Pinging @elastic/kibana-app-arch

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

[clintandrewhall]

As of now, switching the imports to 'plugins/interpreter/types' does not resolve. Let me know if there's something else I should test.

[lukeelmers]

I updated the PR so imports could be done from the top-level (plugins/interpreter rather than plugins/interpreter/types) to remain in line with new platform conventions.

However, it seems that the build fails still when trying to resolve webpack plugins/* aliases within ts files. I've tried updating the x-pack tsconfig but had no luck. The relative imports from within x-pack also fail during build. For now what seemed to work (at least when building locally) was absolute imports from src/legacy/core_plugins/interpreter/public.

I'm optimistic this will fix the CI failures on #37300, but it is something we should come back to fix in a subsequent PR so that webpack aliases can work properly within x-pack.

[clintandrewhall]

Since this works in #37300, I can approve this on behalf of :Canvas. Great working with you on this!

[clintandrewhall]

You might want to take a look at how we're enforcing i18n in Canvas... because if you use the same methodology, we can move those types to OSS as well, (in a future PR).

https://github.com/elastic/kibana/blob/master/x-pack/plugins/canvas/canvas_plugin_src/strings/functions/function_help.ts#L79...L97

[lukeelmers]

Thanks! Will check it out

[lukeelmers]

I'll go ahead and merge so that we can get #37300 in. There are a few follow-up items we'll need to address in subsequent PRs:

• Merge [Canvas] Interpreter type conversion #37300 so we clean up the duplicate code & switch over our imports
• Colocate interfaces for types with the definitions in the interpreter
• Consider how to deal with help text; investigate Canvas implementation as @clintandrewhall suggests above
• Consider re-exporting these from the top-level of plugins/data instead (where this will ultimately live in new platform), instead of from plugins/interpreter
• Switch the interpreter functions over to TS

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request