KILTprotocol SDK Compatibility Issue With Latest Dependencies

Aug 3, 2025 by Henrik Larsen 62 views

SDK No Longer Compatible with Latest Dependencies

Hey everyone,

We've encountered an issue where the KILTprotocol SDK (sdk-js) isn't playing nice with the latest dependency updates. This was flagged by a scheduled test workflow, and it looks like we need to dive in and figure out what's causing the incompatibility.

What's the deal? A scheduled test workflow on the KILTprotocol SDK, designed to ensure compatibility with the most recent dependency versions, has failed. This means that some of the libraries our SDK relies on have been updated, and those updates are causing conflicts.

Why is this important? Keeping our SDK compatible with the latest dependencies is crucial for a few reasons:

Security: Updated libraries often include security patches, so staying current helps protect our users.
Performance: Newer versions can bring performance improvements and bug fixes, making the SDK faster and more reliable.
Features: Sometimes, updates introduce new features that we might want to leverage in the SDK.

Understanding the Incompatibilities

Let's break down what we know about these incompatibilities. The automated test workflow, which is set up to run regularly, essentially checks if the SDK works smoothly with the newest versions of its dependent packages. When a test fails, it's a sign that something's gone wrong – a breaking change in a dependency, a bug in our code that's only exposed by the new version, or some other unforeseen issue.

To get a clearer picture, we need to look at the specific dependencies that were updated and how they might be affecting the SDK. This involves examining the changelogs of the updated packages, understanding their new features or changes, and then tracing how those changes could be impacting our SDK's functionality.

Digging into the Dependency Versions

Below is a summary of the dependency versions against which these tests were run. This information is super helpful because it gives us a snapshot of the exact versions that are causing the problem. We can use this to recreate the issue locally, making it easier to debug and fix.

The versions listed include everything from Babel (our JavaScript compiler) to Polkadot libraries (for blockchain interaction) and even testing tools like Jest and Playwright. Each of these plays a role in the SDK's operation, so a conflict in any of them can cause problems.

@babel/core@npm:7.28.0
@babel/preset-env@npm:7.28.0
@commitlint/cli@npm:9.1.2
@commitlint/config-conventional@npm:9.1.2
@digitalbazaar/ed25519-signature-2020@npm:5.4.0
@digitalbazaar/multikey-context@npm:2.0.1
@digitalbazaar/security-context@npm:1.0.1
@digitalbazaar/vc@npm:6.3.0
@kiltprotocol/asset-credentials@workspace:packages/asset-credentials
@kiltprotocol/augment-api@npm:1.11504.0
@kiltprotocol/chain-helpers@workspace:packages/chain-helpers
@kiltprotocol/config@workspace:packages/config
@kiltprotocol/credentials@workspace:packages/credentials
@kiltprotocol/did@workspace:packages/did
@kiltprotocol/eddsa-jcs-2022@npm:0.1.0
@kiltprotocol/es256k-jcs-2023@npm:0.1.0
@kiltprotocol/jcs-data-integrity-proofs-common@npm:0.1.0
@kiltprotocol/jsonld-suites@workspace:packages/jsonld-suites
@kiltprotocol/legacy-credentials@workspace:packages/legacy-credentials
@kiltprotocol/sdk-js@workspace:packages/sdk-js
@kiltprotocol/sr25519-jcs-2023@npm:0.1.0
@kiltprotocol/type-definitions@npm:1.11502.1
@kiltprotocol/types@workspace:packages/types
@kiltprotocol/utils@workspace:packages/utils
@playwright/test@npm:1.54.2
@polkadot/api@npm:12.4.2
@polkadot/keyring@npm:13.5.4
@polkadot/typegen@npm:12.4.2
@polkadot/types@npm:12.4.2
@polkadot/util-crypto@npm:13.5.4
@polkadot/util@npm:13.5.4
@scure/base@npm:1.2.6
@types/jest@npm:29.5.14
@types/json-pointer@npm:1.0.34
@types/uuid@npm:8.3.4
@typescript-eslint/eslint-plugin@npm:5.62.0
@typescript-eslint/parser@npm:5.62.0
cbor-web@npm:9.0.2
crypto-ld@npm:6.0.0
eslint-config-airbnb-base@npm:14.2.1
eslint-config-prettier@npm:6.15.0
eslint-plugin-import@npm:2.32.0
eslint-plugin-jsdoc@npm:37.9.7
eslint-plugin-license-header@npm:0.2.1
eslint-plugin-prettier@npm:3.4.1
eslint@npm:7.32.0
husky@npm:4.3.8
jest@npm:29.7.0
json-pointer@npm:0.6.2
prettier@npm:2.8.8
rimraf@npm:3.0.2
root-workspace-0b6124@workspace:.
terser-webpack-plugin@npm:5.3.14
testcontainers@npm:10.28.0
ts-jest-resolver@npm:2.0.1
ts-jest@npm:29.4.0
tweetnacl@npm:1.0.3
typedoc@npm:0.24.8
typescript-logging@npm:1.0.1
typescript@patch:typescript@npm%3A4.9.5#optional!builtin<compat/typescript>::version=4.9.5&hash=289587
uuid@npm:10.0.0
varint@npm:6.0.0
webpack-cli@npm:4.10.0
webpack@npm:5.101.0

Potential Causes and What We're Looking For

So, what could be causing these incompatibilities? Here are a few possibilities:

Breaking changes in dependencies: Sometimes, a new version of a library introduces changes that aren't backward-compatible. This means that code that worked with the old version might break with the new one.
Bugs in the new versions: It's also possible that the updated libraries have bugs that are affecting the SDK. While less common, it's something we need to consider.
Tight version constraints: Occasionally, very strict version ranges in our package.json can prevent necessary updates. While seemingly counterintuitive in this scenario, it's a point to consider for future dependency management.

Next Steps: How We're Tackling This

Okay, so we know there's an issue. What's the plan of attack? Here’s how we’re going to get this sorted:

Reproducing the issue: The first step is to recreate the problem locally. We’ll use the dependency versions from the test run to set up an environment that mirrors the one where the tests failed. This allows us to debug effectively and see the errors firsthand.
Identifying the culprit: Once we can reproduce the issue, we'll start narrowing down which dependency (or dependencies) is causing the conflict. This might involve updating dependencies one by one and running tests to see which update breaks things.
Implementing a fix: After we've identified the problematic dependency, we have a few options. We might need to update our code to be compatible with the new version, or we might need to constrain the dependency version in our package.json to prevent the update from happening. In some cases, we might even need to contribute a fix to the dependency itself.

Constraining Dependency Ranges or Introducing Fixes

One of the key strategies here is to figure out whether we need to constrain the dependency ranges in our package.json file. This file essentially tells Node.js which versions of our dependencies are allowed. By setting specific ranges, we can prevent automatic updates to versions that might break our code. This is a bit of a balancing act, though, because we also want to stay up-to-date with the latest security patches and features.

Alternatively, we might need to introduce fixes directly into our SDK. This could involve tweaking our code to work with the new dependency versions or even submitting patches to the dependencies themselves if we find a bug.

Diving Deeper into Specific Dependencies

Now, let’s zoom in on some of the dependencies that might be causing trouble. Looking at the list, some key areas to investigate include:

@polkadot/*: These packages are crucial for interacting with the Polkadot blockchain. Updates here could affect how we submit transactions, handle accounts, or interact with chain state.
@digitalbazaar/*: These libraries are related to digital signatures and cryptography, so changes here could impact our security features.
@babel/*: Babel is our JavaScript compiler, so updates could affect how our code is transformed and bundled.

The Importance of Continuous Integration

This whole situation highlights the importance of continuous integration (CI) in our development process. Our scheduled test workflows are a form of CI, and they're designed to catch these kinds of issues early. By automatically running tests with the latest dependencies, we can identify problems before they make their way into production.

This proactive approach saves us time and headaches in the long run. It’s much easier to fix a compatibility issue in a controlled environment than it is to debug a broken feature in a live system.

Keeping You in the Loop

We’ll keep you guys updated on our progress as we work through this. We'll post updates here as we identify the root cause and implement a solution.

In the meantime, if you have any insights or have experienced similar issues, please feel free to share them! Your input can help us resolve this more quickly.

Thanks for your understanding and patience as we work to ensure the KILTprotocol SDK remains stable and reliable.