Kibana: New Platform doesn't seem to work with `plugin.paths` attribute in yml

[stacey-gammon]

Running yarn start --plugin-path test/plugin_functional/plugins/core_plugin_a works fine, but running yarn start --config test/plugin_functional/kibana.demo-plugins.yml --no-base-path

where the config file has only:

plugins.paths: [
  "test/plugin_functional/plugins/core_plugin_a",
]

gives the error:

 FATAL  Error: Cannot find module 'test/plugin_functional/plugins/core_plugin_a/server'

Not sure why the difference.

cc @joshdover @rudolf

I'm also not sure what these paths should be, since using a legacy path gives an error as well:

  log   [21:14:57.082] [warning][legacy-plugins] Unable to scan directory for plugins "test/plugin_functional/plugins/kbn_tp_embeddable_explorer"

[elasticmachine]

Pinging @elastic/kibana-platform (Team:Platform)

[mistic]

I'll just left here the feedback received from @joshdover

It looks like plugins.paths is not support on NP for now intentionally in order to force plugins to use relative imports.

[pgayvallet]

Not sure why the difference.

When using

yarn start --plugin-path test/plugin_functional/plugins/core_plugin_a

The pathCollector in

https://github.com/elastic/kibana/blob/bf04235dae35452061cc7ea3d86d96c19a58206c/src/cli/serve/serve.js#L55-L61

automatically converts the path to an absolute one by appending process.cwd, meaning that opts.pluginPath in

https://github.com/elastic/kibana/blob/bf04235dae35452061cc7ea3d86d96c19a58206c/src/cli/serve/serve.js#L145-L154

is already /absolute-path-to/kibana/test/plugin_functional/plugins/core_plugin_a'

When using a config file containing

plugins.paths: [
  "test/plugin_functional/plugins/core_plugin_a",
]

The same conversion is not performed, as it's directly read from the config reader.

Not sure this should be considered a bug.

Maybe we should just update the documentation of

https://github.com/elastic/kibana/blob/24542c3ad747ff6bb024e315e5475fb6cdb04a77/src/core/server/plugins/plugins_config.ts#L30-L33

To explicitly state that we are expecting absolute paths?

@joshdover wdyt?

[restrry]

To explicitly state that we are expecting absolute paths?

Makes sense to me, we already have the same requirements for legacy plugins.scanDirs (also not documented though) https://github.com/elastic/kibana/blob/18e10759792cb2fe6a99607d2e19cf046bd1ee79/src/cli/cluster/cluster_manager.ts#L178

We can add absolute path validation https://nodejs.org/api/path.html#path_path_isabsolute_path to the config schema https://github.com/elastic/kibana/blob/18e10759792cb2fe6a99607d2e19cf046bd1ee79/src/core/server/plugins/plugins_config.ts#L33

[joshdover]

Makes sense to me 👍

We should also consider what we want to do with scanDirs. I don't see any particular problem with supporting this. I think the "we need to encourage relative paths" priority has created more problems than it's really solved. Ideally the location a plugin is developed in is irrelevant to how it's executed in production, but to achieve that I think we will need to either support some module aliasing or bundling server-side code at plugin build time.