tabby
tabby copied to clipboard
Eugeny
feat(tabby-ssh): use string token for providing SSHProfileImporter
Until now we were using a Type Token (class SSHProfileImporter) to inject importers into the SSHProfilesService. However, this made external plugins unable of providing their own importers, since the reference to SSHProfileImporter from the built-in plugins was different to the one from any external plugin.
This probably has to do with webpack bundling different "instances" of the class SSHProfileImporter between built-in and external plugins. The implementation was the same (since the class was being imported from the tabby-ssh package), but the memory reference was different, so the dependency injector wouldn't match the external ones.
By using a string as DI Token, we ensure plugins can use a token that the injector can match, since strings are compared by value instead of reference.
Hi again, I had some problems when trying to make my plugin work, and I found out my importer wasn't being injected because of this.
You said it worked for you when you tried to debug it. May I ask, did you clone my repo inside the tabby project folder when doing so? That way it does work because webpack was bundling a single "instance" of the SSHProfileImporter class, so the DI tokens matched. Also, we could try if reverting the injector back to SSHProfilesService's constructor works with this new approach if you prefer it.
In any case, I took the liberty of opening this PR right away, but if you think this approach to making custom importers available is too hacky, or might cause problems in the future, and prefer avoiding it, I understand.
I've tested it from a separate repo, launching it with TABBY_PLUGINS=$(pwd) .... Tabby doesn't actually care where a plugin is external or not except for the load order - "internal" plugins are still built into separate webpack bundles that reference each other.
External plugins still can use class-based injection tokens - as long as tabby-* modules are correctly set as webpack externals and the plugin doesn't bundle its own copy of tabby-* or @angular/* modules.
I suspect your issue could be caused by a different node_modules search order somehow? You can verify it by temporarily renaming your node_modules after the plugin has been built once and seeing if it changes the behaviour.
@Eugeny Hi, I'm sorry, I've been a bit busy and haven't been able to check on this. I'll try and see if I can make it work with class-based injection.