Can't uninstall plugin in UI due to name inconsistencies

[garrettjstevens]

Runtime plugins have two names, the name in the config file and the name in the plugin class. For example, the current Biothings plugin in the plugin store has this config:

{
  "name": "Biothings",
  // ...other stuff
}

And this plugin class name:

export default class extends Plugin {
  name = 'MyGeneAdapter'

  install(pluginManager: PluginManager) {
    // stuff
  }
}

When you see this plugin in the plugin store, it looks like this: But when you install it, it uses the plugin class name instead:

The name inconsistencies cause a few problems:

• The plugin still shows available to install even when it's already installed
• It shows a lock icon and doesn't allow removing the plugin, even if it's a session plugin
• In admin mode, it doesn't show a lock icon, but when you try to remove the plugin it doesn't actually get removed

There probably needs to be a way to deduplicate the two names or ensure they are the same.

[cmdcolin]

Interesting...Could we remove one or the other? E.g. just have the URL and rely on the static name field, or just use the name from the config?

[garrettjstevens]

Possibly, but we might have to re-work some things. The problem I see is that JBrowse needs the config name in order to know what global variable the plugin got added to, so you can't access the plugin to see the class attribute name without the config name. But core plugins don't have a config name, so they need to keep the plugin class attribute name.

[garrettjstevens]

Also, the plugin removal in the UI only works currently if the class attribute name is the config name with "Plugin" on the end. For example, the MsaView plugin works because the config name is "MsaView" and the class attribute name is "MsaViewPlugin".

[garrettjstevens]

Some observations from backlog meeting:

• Could try to validate name matching when the plugin gets loaded, the unload the plugin and show an error
• Could add a check to plugin integration testing template
• Could add a check when validating plugins for the plugin store

Also, another solution @cmdcolin suggested is that we could try making plugins be esm modules that are imported with asynchronous import and then we don't have to give them a global name in the config.