Changing publisher name breaks dependencies

microsoft / vscode-node-debug

A VS Code debug adapter for node

Other

261 stars 96 forks source link

Changing publisher name breaks dependencies #56

Closed MSLaguana closed 8 years ago

MSLaguana commented 8 years ago

We have an extension which depends on this one, and we've just found out that in the upcoming release of vscode, since the publisher name has changed we are going to be broken: https://github.com/Microsoft/vscode-react-native/issues/155

What do you propose as the best solution? If we change to taking a dependency on the new publisher+extension name, will that work in both newer and older versions of vscode, or will we need to make a breaking change and not support previous versions?

@weinand

weinand commented 8 years ago

/cc @egamma

egamma commented 8 years ago

The extensions API https://code.visualstudio.com/docs/extensionAPI/vscode-api#_extensions provides reflective methods to find and activate extensions. We have never done this, but you could use this API to implement a backward compatible way to deal with the dependencies.

In your extension's activate method you can find which extensions are installed vscode.extensions.getExtension(). An extension's is API isActive and activate to install an extension manually.

egamma commented 8 years ago

/cc @alexandrudima to confirm the proposal.

weinand commented 8 years ago

@MSLaguana please let me know if this proposal doesn't work for you.

alexdima commented 8 years ago

What @egamma suggests might work in this case:

change your package.json to not have extensionDependencies anymore.
this means that your extension will get loaded and activated independently of node-debug.
you can, in your activate method use the extensions namespace to reflect and find if node-debug is installed (under the old publisher or the new publisher, at what version, etc.).
proceed or show error message, etc.

MSLaguana commented 8 years ago

We do currently use the vscode.extensions api to find the path of the node-debug extension so we can wrap around it in our debug adapter, so I believe that this approach should work for us. I'm a little concerned that we'd be losing some futureproofing by removing the extensionDependencies though, since if we had not specified that in the first place we would have been unaware of this failure until runtime, rather than finding out immediately on installation that there was an issue. Still, it seems that this will be the best approach for us. Thanks,