在新平台的当前草案中，插件由字符串标识（例如，定义依赖项）。
我想讨论以某种方式使这个 id 更独特，例如通过使用像org.elastic.timelion或de.timroes.demo-plugin这样的 java-ish 名称。 这样就不会再发生命名冲突了，因为人们使用的名字太简单了，而且你有多个名为3dcharts的插件。
另一种命名方案可能是使用类似 npm 的范围，例如@elastic/timelion或@timroes/demo-plugin 。 我认为这两种建议各有利弊。
使用范围更接近 JavaScript，如果npm应该用于插件管理，这可能是一个优势。 我看到了 Java-ish 名称的优势，我假设很多人没有 npm 用户，并且实际上会使用实际上不属于他们的@scope ，而我很少遇到任何人，那将无法为私人或公司域建立一个崇高的域名。
无论唯一 ID 具有何种格式，直接在新平台中强制执行该格式并禁止任何不符合该命名方案的新插件可能是有意义的。
<discuss>
timroes
所有3条评论
也许内置核心插件的例外是有意义的，它们不需要前缀，但我也看到了从头开始引入例外的几个缺点。
timroes
于 2017-07-07
我可以看到这样做的好处，但这也是我们将来可以随时解决的问题。 我们没有流行的重复插件 id，当存在重复的插件 id 时，您想要同时安装这两个插件的情况非常罕见。 我确实喜欢这种对新平台鼓励的广泛插件开发潜力的前瞻性思考，但是让我们在以后真正成为问题时处理这个问题。
@elastic/kibana-platform 你怎么看？
epixa
于 2018-05-05
我现在要关闭它作为一个不会修复的问题。 正如我在之前的评论中提到的，我认为这里的想法是合理的，但我们实际上还没有解决这个问题。 如果/当它在实践中成为一个常见问题时，我们可以恢复这个线程或打开一个新线程。
epixa
于 2019-04-23
相关问题
stacey-gammon
·
3评论
mark54g
·
3评论
ctindel
·
3评论
bradvido
·
3评论
bhavyarm
·
3评论
最有用的评论
我可以看到这样做的好处，但这也是我们将来可以随时解决的问题。 我们没有流行的重复插件 id，当存在重复的插件 id 时，您想要同时安装这两个插件的情况非常罕见。 我确实喜欢这种对新平台鼓励的广泛插件开发潜力的前瞻性思考，但是让我们在以后真正成为问题时处理这个问题。
@elastic/kibana-platform 你怎么看？