Initial work to add autocomplete functionality for the painless language within the monaco editor. This first phase focuses on autocompletion for class and class members given a Painless context. It has been integrated with Painless Lab for ease of testing. Integration across other plugins will be handled in a separate PR.

TODO:

• Delete dummy context files, which exports static JSON to handle autocomplete, in favor of incorporating the data directly from ES
  • Remove reference to forked ES branch in script (dependent on code merged to ES master branch)
• Move logic from the painless_lab plugin into the @kbn/monaco package
• Support ability to specify a painless context within editor
• Update current painless editors to consume the language features
  • Painless lab
  • Runtime field in index templates UI Will open separate PR for integration (reverted via 9b15fdf)
  • Script editor and condition editor in ingest node pipelines Will open separate PR for integration (reverted via 9b15fdf)
• Add readme to @kbn/monaco/painless

Summary

Autocomplete generation

The autocomplete definitions are generated by cloning the ES repo and copying over the allowed classes per context stored here.

Note: This data is currently only available on a feature branch, and has not yet been merged to master. It is also the same information available via the painless context API: GET /_scripts/painless/_context?context=<context>.

The data OOTB is not in a format that can be easily consumed by monaco for autocompletion. Since this is all static content, rather than manipulate the data at runtime, the script that copies the data over also reformats it. All related code can be found under the scripts directory. The script should only need to be run once per release.

There are >30 different painless contexts available. Each context definition is ~1MB. I’ve only added support for a select few contexts for now. Long term, I think we probably need to reevaluate how we handle this if we intend to add more.

Implementation

Please refer to the README for an explanation of the general architecture.

Testing

This work has been integrated in Painless Lab, so testing can be performed there.

What should work?

1. Autocompletion for keywords (if, else, for, etc.)
2. Any word prefixed by “new “ should only return available constructors
3. Typing a class follow by a dot (e.g., “Math.”), should return all available methods or fields for that class.
4. Autocompletion for document fields. In order to enable this, the consumer must supply the available fields to the editor. This isn’t applicable in Painless Lab, but for testing purposes you can temporarily edit the editor.tsx file in Painless Lab to pass fields to the suggestion provider. For example:

  const fields = [
    {
      name: 'field1',
      type: 'float',
    },
    {
      name: 'field2',
      type: 'boolean',
    },
    {
      name: 'field3',
      type: 'boolean',
    },
    {
      name: 'field4',
      type: 'boolean',
    },
  ];

  const suggestionProvider = PainlessLang.getSuggestionProvider(context, fields);

With this, autocompletion should be available for the doc keyword, and the available fields should populate when you type the ' character inside the bracket, e.g., doc['].

5. Changing the context should change the autocomplete definitions that are returned. Painless Lab by default uses the painless_test context, but the UI allows you to switch to score or filter as well.

Release note

Painless Lab in DevTools now supports autocompletion for keywords, as well as class and class members for the Painless language based on a given context.