Kibana: Using unique ids for plugins in new platform

[timroes]

In the current draft of the new platform, plugins are identified by a string (e.g. to define dependencies).

I would like to discuss making this ids in some way more unique, e.g. by using a java-ish name like org.elastic.timelion or de.timroes.demo-plugin. That way there couldn't happen naming collisions anymore, because people use too simple names and you have multiple plugins named e.g. 3dcharts.

Another naming scheme could be using npm-like scoping, e.g. @elastic/timelion or @timroes/demo-plugin. I think both suggestions have their pros and cons.

Using scoping is more JavaScript-ish and might be an advantage if npm should ever be used for plugin management. I see the advantage in Java-ish names, that I assume that a lot of people don't have an npm user and would actually use a @scope not actually belonging to them, whereas I've seldom met anyone, that wouldn't be able to build a revere domain name for a private or company domain.

Whatever format that unique id have, it might make sense to enforce that format in the new platform directly and forbid any new plugins, that don't comply with that naming scheme.

<discuss>

[timroes]

Maybe an exception for builtin core plugins could make sense, that these won't need a prefix, but I see also several drawbacks of introducing exceptions right from the start again.

[epixa]

I can see the benefit of this, but this is also a problem we can solve at any time in the future. We don't have an epidemic of duplicate plugin ids, and when there are duplicate plugin ids in the wild, it's exceptionally rare that you'd want to install both of those plugins at one time. I do like this kind of forward thinking about the potential for widespread plugin development that the new platform encourages, but let's deal with this at a later time when it actually becomes a problem.

@elastic/kibana-platform what do you think?

[epixa]

I'm going to close this out as a wont-fix for now. As I mentioned in my previous comment, I think the ideas here are sound but that we're not actually hitting this problem yet. We can resurrect this thread or open a new one if/when it becomes a common issue in practice.