search

jolocom / jolocom-sdk

A tool kit for integration with SSI
Apache License 2.0
31 stars 9 forks source link

Outdated SDK package dependencies #126

Open valentinyanakiev opened 3 years ago

valentinyanakiev commented 3 years ago

Description

Jolocom SDK has a lot of outdated dependencies - and this creates dependency hell for 3rd party integration.

E.g. We, the Alkemio team, rely server-side on nodeJS with mysql as the primary storage driver, used with typeORM as ORM layer and nestJS as a framework. We recently moved to the latest version of nestJS and moved to typeORM 0.2.35 (there is already 0.2.37 out).

Jolocom SDK, on the other hand, relies on a 2-year old typeORM release - 0.2.24, which is already incompatible with our code. It also relies on jolocom/sdk-storage-typeorm that has the same typeORM release as a peer dependency (0.2.24).

As a direct result of this outdated package dependencies we have isolated the jolocom integration for now in our codebase. We'd like to soon re-integrate it and start using it.

TODO

P.S. It is also worth noting that other dependencies are also quite outdated, e.g. you are a major vershion behind (3 vs 4) on typescript etc. While that is not a direct blocker for us it might be good to update it (and analyze + update the rest of the packages where possible) to streamline external contribution and prevent others from having similar dependency issues as we have.

mnzaki commented 3 years ago

Thank you @valentinyanakiev for the report! We are busy updating our entire stack and preparing for a version 2 of the SDK. All these issues will be handled by then.

Of course we are open to PRs if you have already worked on this yourself! Just be sure to sign the CLA (follow the steps in the CONTRIBUTING document)

techsmyth commented 3 years ago

Hey @mnzaki what is the timeline for v2?

At the moment Jolocom SDK integration is completely removed due to the version compatibility issues above. And given we likely will need to work on our SSI integration this month as part of our recent eSSIF lab grant we need to decide how to proceed.

I see a few options:

  1. we fork, try to update the dependencies ourselves and if we succeed we submit a PR. Plus is that it is in our own hands. Minus is that we are not deeply familiar with the SDK dependencies, so outcome and effort is hard to predict.
  2. we wait for v2. Plus: latest version. Minus: need to know the timeline / when it would be usable by us.
  3. we ask you very nicely to fix this. Plus: most effective use I think of everyone's time. Minus: I know you guys are swamped.

Clearly we hope for #3. #2 depends on your answer re timeline. #1 is uncertain re outcome / effort.

This is more critical than the docker image base issue.

Thoughts?