Skip to content

RFC: Install user-defined dependencies centrally, instead of letting adapters handle them  #2006

Closed
@AlCalzone

Description

@AlCalzone

"Manually" installing dependencies in a sub-package of our "install" project (/opt/iobroker/package.json) once worked fine, but increasingly collides with what npm does while managing the dependencies. We already stopped doing a separate npm install inside the adapter directories in #1339, but some adapters still do this, leading to weird issues.

I therefore propose we get rid of this too and do the installation in a central location, adding the dependencies to our root package.json. To avoid conflicts, we need to fake-namespace these packages, which npm supports using the npm: protocol. Npm supports this since 6.9.0 (npm/cli#3):

// package.json
"dependencies": {
  //... all adapters etc., as usual
  // namespaced user-defined dependencies of iobroker.javascript, instance 0:
  "@iobroker-javascript.0/axios": "npm:[email protected]", // Here javascript.0 has [email protected] as its dependency
  "@iobroker-javascript.0/alcalzone-pak": "npm:@alcalzone/[email protected]", // scoped dependencies need to be escaped. I propose omitting the leading @ and replacing / with - (_ would also be fine)
  // ... likewise for other adapters/instances
}

This has the downside that the adapters need to be able to redirect the require to the correct package name, e.g. javascript.0 would have to require @iobroker-javascript.0/axios instead of just axios, but we can expose a utility for this too.

The upside would be that versioning these dependencies would become a bit more manageable, and another adapter installing the same one would not accidentally cause a conflict. This way we can also support multiple instances of javascript have different versions of the same package, since the fake scopes are instance-specific. In addition, maybe the adapters wouldn't even have to store their dependencies separately anymore, but could rather enumerate them from the root package.json.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions