-
-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[enhancement]: Allow to install adapters which are scoped packages (Vendor-feature) #2942
Comments
This will introduce a problem with naming scope. Currently ioBroker.myadapter package name guarantees that exactly one adapter named myadapter can exist due to naming rules on github. Inventing scoped names we will run into the situation that ioBroker.shelly might exist at npm. No idea how to handle this situation. Maybe we would need to create some registration database or something like this. In addition all tools / checkers must be extended to handle scoped packages. (But thats not a problem only work to be planned and done) |
It is really a vendor-specific feature, these repos cannot be checked as they are likely not be publicly available and probably are for one single user or company. Naming issues in general yes, but on repo level one will be the applied one (multi repo feature). We will refine this ticket in the next core meeting so lets see. |
One solution without changes could eventualkly be to use a normal adapter environment BUT to put the real code into a dependent scoped package. This way no changes to ioBroker would be required but user could not install the adapter unless they have access to the scoped package. main.js in standard could simply do nothing but log a message and / or call into the scoped and hence protected pacakge. Eventually io-package.json could be extended to allow admin / js-controlelr to check and output a clear messages instead of crashing due to insufficiengt access righgts to dependent package. |
As long as iob install @foxriver76/ioBroker.shelly or something like this as possible users will use it to fork variants and this will be suggested at forum for sure. We should consider this and eventually restrict in some way. Maybe we could / should enforce that the scope name is part of the adapter name? In general I see the usages and I understand that this is required for a commercial environement. |
Scoped packages are not meant for users, no scoped package should ever be in an official beta or stable repo see initial post.
This is a very specific case. In general, the feature is not a feature anyone would care about except from someone who writes an adapters which is meant for a single company. I would not allow to set
it won't be possible! See https://github.com/ioBroker/ioBroker.js-controller/pull/2943/files as a proposed implementation, it only works if the |
No existing issues.
Description
Currently adapters cannot be published as scoped packages because the controller cannot handle it. We could allow to also install scoped packages.
Why?
If I as a ioBroker consultant want to provide packages which are not public available to my customer, the way to go nowadays is to use a private registry, likely GitHub packages. Then some would create a scope for their customer or org and the customer should get access to all the adapters (packages) inside this scope. Hence, scoped packages are the way to go.
On the customer you would just need to put an
.npmrc
file inhome/iobroker/
with a token with read access to the scope. Then if the customer has configured a repo containing this adapter it will show up in admin and will be installable.Minimal Example: https://www.moritz-heusinger.de/static/repositories/fleck.json see
packetName
attribute.In general this feature should never be used in the official stable and beta repository as there is no necessarity for scoped packages!
How?
We could allow e.g. a
packetName
attribute in the repository which represents the real package name (with scope) andon install simply alias it to the normal package name.Downsides:
The text was updated successfully, but these errors were encountered: