build(deps): add resolutions: axios>=0.27.2, nano>=10.0.0 #2821

petermetz · 2023-10-20T20:50:38Z

This is a workaround for the problem Peter intorduced in the build with
an earlier commit where he upgraded axios to 1.5.1 universally.
The above had lead to a problem with the nano package, which is a
dependency of the fabric node SDK packages.

The longer term solution is to migrate to the newer Fabric Gateway
client SDK and completely remove the older fabric dependencies from
the project, but until we can do that (a big undertaking) we have to
be content with this shorter term workaround and hope that axios 0.27.2
does not turn out to be vulnerable critically (because that would force
our hand with upgrades again).

Partially addresses #2807 (not a full fix)

Signed-off-by: Peter Somogyvari [email protected]

Pull Request Requirements

Rebased onto upstream/main branch and squashed into single commit to help maintainers review it more efficient and to avoid spaghetti git commit graphs that obfuscate which commit did exactly what change, when and, why.
Have git sign off at the end of commit message to avoid being marked red. You can add -s flag when using git commit command. You may refer to this link for more information.
Follow the Commit Linting specification. You may refer to this link for more information.

Character Limit

Pull Request Title and Commit Subject must not exceed 72 characters (including spaces and special characters).
Commit Message per line must not exceed 80 characters (including spaces and special characters).

A Must Read for Beginners
For rebasing and squashing, here's a must read guide for beginners.

This is a workaround for the problem Peter intorduced in the build with an earlier commit where he upgraded axios to 1.5.1 universally. The above had lead to a problem with the nano package, which is a dependency of the fabric node SDK packages. The longer term solution is to migrate to the newer Fabric Gateway client SDK and completely remove the older fabric dependencies from the project, but until we can do that (a big undertaking) we have to be content with this shorter term workaround and hope that axios 0.27.2 does not turn out to be vulnerable critically (because that would force our hand with upgrades again). Partially addresses hyperledger-cacti#2807 (not a full fix) Signed-off-by: Peter Somogyvari <[email protected]>

izuru0

LGTM

- Replace deprecated ipfs-http-client with kubo-rpc-client. - kubo-rpc-client must be imported dynamically since it's ESM-only and we still use CJS. Depends on: hyperledger-cacti#2821 Signed-off-by: Michal Bajer <[email protected]>

jagpreetsinghsasan

LGTM

- Replace deprecated ipfs-http-client with kubo-rpc-client. - kubo-rpc-client must be imported dynamically since it's ESM-only and we still use CJS. Depends on: hyperledger-cacti#2821 Signed-off-by: Michal Bajer <[email protected]>

@outSH

- Replace deprecated ipfs-http-client with kubo-rpc-client. - kubo-rpc-client must be imported dynamically since it's ESM-only and we still use CJS. Peter's additional changes: --------------------------- build(typescript): project-wide fixes to allow us to use ESM-only deps Apologies for the huge diff, this can't be broken down to smaller changes that would still compile because of cross-package dependencies. I realize that this change is not exactly the optimal solution, but it is probably a step in the right direction. If I somehow found the time to submit pull requests to the libraries that I needed to fork and re-publish (see details below) and then get the changes onto the upstream and get them released as the official packages, then we could (in theory) arrive at a solution that is the recommended way of fixing these problems (apart from going full ESM-only) This work stands on the shoulders of the previous commits from @outSH and takes a slightly different direction compared to what we've been talking about earlier on account of the problem that the eval-import workaround causes crashes in Jest. Based on the above I went through the following adventures: 1. I migrated the build system of kubo-rpc-client myself so that it correctly exports CJS and ESM and typings for both of those as well, I put that code on my fork [1] and then published it onto npm as well [2] After this, I was hoping that now we could just import the package in our CJS code without issues, but what really happened is that instead of crashing at the require call that pull in kubo itself, it started crashing deeper in the require stack where kubo itself was requiring it's own ESM only dependencies (of which there seem to be at least 10 or 15). At this point I realized that me migrating and self-publishing all of these additional packages might not be worth the effort and started looking for something easier. 2. I gave dynamic imports + moduleResultion=Node16 as my next attempt to get our build back to working order. With this, the kubo-rpc-client can now be imported dynamically without issues in packages that declare themselves as resolving modules as "Node16" in their tsconfig.json Other issues here were encountered because not all of our ESM only packages are used in a way that they can be imported dynamically (for example if their types are part of our own types or are being re-exported). The two libraries with this problem were `run-time-error` and `socket.io-client` for both of which I ended up going through the same treatment as for kubo-rpc-client above (but this time my effort wasn't) in vain. They work and so I did some search and replace in the entire codebase to use these re-published packages with the correct types: [3] [4] [5] [6] 3. After this the project build was working, but Jest was still failing with compiler errors which I determined to happen because it uses the root tsconfig.json file for it's internal TS compilation and that root tsconfig.json file was not setting module resolution to Node16. 4. After fixing that the final hurdle (hopefully) was to ensure that jest gets execued with the custom node option as below: NODE_OPTIONS=--experimental-vm-modules yarn jest [1] https://github.com/petermetz/js-kubo-rpc-client-esm-cjs [2] https://www.npmjs.com/package/kubo-rpc-client-esm-cjs [3] https://github.com/petermetz/socket.io-client [4] https://www.npmjs.com/package/socket.io-client-fixed-types [5] https://github.com/petermetz/RuntimeError [6] https://www.npmjs.com/package/run-time-error-cjs Huge thanks for https://arethetypeswrong.github.io/ a tool I used extensively to create the fixes for the libraries above. One more thing that I tried just to collect more data points was to set the moduleResultion project-wide to Node16 via setting it in the root tsconfig.base.json but this broke the compiler itself, as in, there is a bug in the Typescript compiler in v4.x as seen here: microsoft/TypeScript#51221 So this is one more reason for us to upgrade to 5.x as soon as possible. I also needed to add "run-time-error" to the root package.json as a dependency because it was accidentally providing that to some sub-packages and when we moved to "run-time-error-cjs" the tests that install plugins from npm started failing (because those releases are still using "run-time-error" and not "run-time-error-cjs") ------------------------------------ Fixes hyperledger-cacti#2807 Fixes hyperledger-cacti#2852 Depends on: hyperledger-cacti#2821 Co-authored-by: Peter Somogyvari <[email protected]> Signed-off-by: Peter Somogyvari <[email protected]> Signed-off-by: Michal Bajer <[email protected]>

@outSH

- Replace deprecated ipfs-http-client with kubo-rpc-client. - kubo-rpc-client must be imported dynamically since it's ESM-only and we still use CJS. Peter's additional changes: --------------------------- build(typescript): project-wide fixes to allow us to use ESM-only deps Apologies for the huge diff, this can't be broken down to smaller changes that would still compile because of cross-package dependencies. I realize that this change is not exactly the optimal solution, but it is probably a step in the right direction. If I somehow found the time to submit pull requests to the libraries that I needed to fork and re-publish (see details below) and then get the changes onto the upstream and get them released as the official packages, then we could (in theory) arrive at a solution that is the recommended way of fixing these problems (apart from going full ESM-only) This work stands on the shoulders of the previous commits from @outSH and takes a slightly different direction compared to what we've been talking about earlier on account of the problem that the eval-import workaround causes crashes in Jest. Based on the above I went through the following adventures: 1. I migrated the build system of kubo-rpc-client myself so that it correctly exports CJS and ESM and typings for both of those as well, I put that code on my fork [1] and then published it onto npm as well [2] After this, I was hoping that now we could just import the package in our CJS code without issues, but what really happened is that instead of crashing at the require call that pull in kubo itself, it started crashing deeper in the require stack where kubo itself was requiring it's own ESM only dependencies (of which there seem to be at least 10 or 15). At this point I realized that me migrating and self-publishing all of these additional packages might not be worth the effort and started looking for something easier. 2. I gave dynamic imports + moduleResultion=Node16 as my next attempt to get our build back to working order. With this, the kubo-rpc-client can now be imported dynamically without issues in packages that declare themselves as resolving modules as "Node16" in their tsconfig.json Other issues here were encountered because not all of our ESM only packages are used in a way that they can be imported dynamically (for example if their types are part of our own types or are being re-exported). The two libraries with this problem were `run-time-error` and `socket.io-client` for both of which I ended up going through the same treatment as for kubo-rpc-client above (but this time my effort wasn't) in vain. They work and so I did some search and replace in the entire codebase to use these re-published packages with the correct types: [3] [4] [5] [6] 3. After this the project build was working, but Jest was still failing with compiler errors which I determined to happen because it uses the root tsconfig.json file for it's internal TS compilation and that root tsconfig.json file was not setting module resolution to Node16. 4. After fixing that the final hurdle (hopefully) was to ensure that jest gets execued with the custom node option as below: NODE_OPTIONS=--experimental-vm-modules yarn jest [1] https://github.com/petermetz/js-kubo-rpc-client-esm-cjs [2] https://www.npmjs.com/package/kubo-rpc-client-esm-cjs [3] https://github.com/petermetz/socket.io-client [4] https://www.npmjs.com/package/socket.io-client-fixed-types [5] https://github.com/petermetz/RuntimeError [6] https://www.npmjs.com/package/run-time-error-cjs Huge thanks for https://arethetypeswrong.github.io/ a tool I used extensively to create the fixes for the libraries above. One more thing that I tried just to collect more data points was to set the moduleResultion project-wide to Node16 via setting it in the root tsconfig.base.json but this broke the compiler itself, as in, there is a bug in the Typescript compiler in v4.x as seen here: microsoft/TypeScript#51221 So this is one more reason for us to upgrade to 5.x as soon as possible. I also needed to add "run-time-error" to the root package.json as a dependency because it was accidentally providing that to some sub-packages and when we moved to "run-time-error-cjs" the tests that install plugins from npm started failing (because those releases are still using "run-time-error" and not "run-time-error-cjs") ------------------------------------ Fixes hyperledger-cacti#2807 Fixes hyperledger-cacti#2852 Depends on: hyperledger-cacti#2821 Co-authored-by: Peter Somogyvari <[email protected]> Signed-off-by: Peter Somogyvari <[email protected]> Signed-off-by: Michal Bajer <[email protected]>

@outSH

- Replace deprecated ipfs-http-client with kubo-rpc-client. - kubo-rpc-client must be imported dynamically since it's ESM-only and we still use CJS. Peter's additional changes: --------------------------- build(typescript): project-wide fixes to allow us to use ESM-only deps Apologies for the huge diff, this can't be broken down to smaller changes that would still compile because of cross-package dependencies. I realize that this change is not exactly the optimal solution, but it is probably a step in the right direction. If I somehow found the time to submit pull requests to the libraries that I needed to fork and re-publish (see details below) and then get the changes onto the upstream and get them released as the official packages, then we could (in theory) arrive at a solution that is the recommended way of fixing these problems (apart from going full ESM-only) This work stands on the shoulders of the previous commits from @outSH and takes a slightly different direction compared to what we've been talking about earlier on account of the problem that the eval-import workaround causes crashes in Jest. Based on the above I went through the following adventures: 1. I migrated the build system of kubo-rpc-client myself so that it correctly exports CJS and ESM and typings for both of those as well, I put that code on my fork [1] and then published it onto npm as well [2] After this, I was hoping that now we could just import the package in our CJS code without issues, but what really happened is that instead of crashing at the require call that pull in kubo itself, it started crashing deeper in the require stack where kubo itself was requiring it's own ESM only dependencies (of which there seem to be at least 10 or 15). At this point I realized that me migrating and self-publishing all of these additional packages might not be worth the effort and started looking for something easier. 2. I gave dynamic imports + moduleResultion=Node16 as my next attempt to get our build back to working order. With this, the kubo-rpc-client can now be imported dynamically without issues in packages that declare themselves as resolving modules as "Node16" in their tsconfig.json Other issues here were encountered because not all of our ESM only packages are used in a way that they can be imported dynamically (for example if their types are part of our own types or are being re-exported). The two libraries with this problem were `run-time-error` and `socket.io-client` for both of which I ended up going through the same treatment as for kubo-rpc-client above (but this time my effort wasn't) in vain. They work and so I did some search and replace in the entire codebase to use these re-published packages with the correct types: [3] [4] [5] [6] 3. After this the project build was working, but Jest was still failing with compiler errors which I determined to happen because it uses the root tsconfig.json file for it's internal TS compilation and that root tsconfig.json file was not setting module resolution to Node16. 4. After fixing that the final hurdle (hopefully) was to ensure that jest gets execued with the custom node option as below: NODE_OPTIONS=--experimental-vm-modules yarn jest [1] https://github.com/petermetz/js-kubo-rpc-client-esm-cjs [2] https://www.npmjs.com/package/kubo-rpc-client-esm-cjs [3] https://github.com/petermetz/socket.io-client [4] https://www.npmjs.com/package/socket.io-client-fixed-types [5] https://github.com/petermetz/RuntimeError [6] https://www.npmjs.com/package/run-time-error-cjs Huge thanks for https://arethetypeswrong.github.io/ a tool I used extensively to create the fixes for the libraries above. One more thing that I tried just to collect more data points was to set the moduleResultion project-wide to Node16 via setting it in the root tsconfig.base.json but this broke the compiler itself, as in, there is a bug in the Typescript compiler in v4.x as seen here: microsoft/TypeScript#51221 So this is one more reason for us to upgrade to 5.x as soon as possible. I also needed to add "run-time-error" to the root package.json as a dependency because it was accidentally providing that to some sub-packages and when we moved to "run-time-error-cjs" the tests that install plugins from npm started failing (because those releases are still using "run-time-error" and not "run-time-error-cjs") ------------------------------------ Fixes hyperledger-cacti#2807 Fixes hyperledger-cacti#2852 Depends on: hyperledger-cacti#2821 Co-authored-by: Peter Somogyvari <[email protected]> Signed-off-by: Peter Somogyvari <[email protected]> Signed-off-by: Michal Bajer <[email protected]>

@outSH

- Replace deprecated ipfs-http-client with kubo-rpc-client. - kubo-rpc-client must be imported dynamically since it's ESM-only and we still use CJS. Peter's additional changes: --------------------------- build(typescript): project-wide fixes to allow us to use ESM-only deps Apologies for the huge diff, this can't be broken down to smaller changes that would still compile because of cross-package dependencies. I realize that this change is not exactly the optimal solution, but it is probably a step in the right direction. If I somehow found the time to submit pull requests to the libraries that I needed to fork and re-publish (see details below) and then get the changes onto the upstream and get them released as the official packages, then we could (in theory) arrive at a solution that is the recommended way of fixing these problems (apart from going full ESM-only) This work stands on the shoulders of the previous commits from @outSH and takes a slightly different direction compared to what we've been talking about earlier on account of the problem that the eval-import workaround causes crashes in Jest. Based on the above I went through the following adventures: 1. I migrated the build system of kubo-rpc-client myself so that it correctly exports CJS and ESM and typings for both of those as well, I put that code on my fork [1] and then published it onto npm as well [2] After this, I was hoping that now we could just import the package in our CJS code without issues, but what really happened is that instead of crashing at the require call that pull in kubo itself, it started crashing deeper in the require stack where kubo itself was requiring it's own ESM only dependencies (of which there seem to be at least 10 or 15). At this point I realized that me migrating and self-publishing all of these additional packages might not be worth the effort and started looking for something easier. 2. I gave dynamic imports + moduleResultion=Node16 as my next attempt to get our build back to working order. With this, the kubo-rpc-client can now be imported dynamically without issues in packages that declare themselves as resolving modules as "Node16" in their tsconfig.json Other issues here were encountered because not all of our ESM only packages are used in a way that they can be imported dynamically (for example if their types are part of our own types or are being re-exported). The two libraries with this problem were `run-time-error` and `socket.io-client` for both of which I ended up going through the same treatment as for kubo-rpc-client above (but this time my effort wasn't) in vain. They work and so I did some search and replace in the entire codebase to use these re-published packages with the correct types: [3] [4] [5] [6] 3. After this the project build was working, but Jest was still failing with compiler errors which I determined to happen because it uses the root tsconfig.json file for it's internal TS compilation and that root tsconfig.json file was not setting module resolution to Node16. 4. After fixing that the final hurdle (hopefully) was to ensure that jest gets execued with the custom node option as below: NODE_OPTIONS=--experimental-vm-modules yarn jest [1] https://github.com/petermetz/js-kubo-rpc-client-esm-cjs [2] https://www.npmjs.com/package/kubo-rpc-client-esm-cjs [3] https://github.com/petermetz/socket.io-client [4] https://www.npmjs.com/package/socket.io-client-fixed-types [5] https://github.com/petermetz/RuntimeError [6] https://www.npmjs.com/package/run-time-error-cjs Huge thanks for https://arethetypeswrong.github.io/ a tool I used extensively to create the fixes for the libraries above. One more thing that I tried just to collect more data points was to set the moduleResultion project-wide to Node16 via setting it in the root tsconfig.base.json but this broke the compiler itself, as in, there is a bug in the Typescript compiler in v4.x as seen here: microsoft/TypeScript#51221 So this is one more reason for us to upgrade to 5.x as soon as possible. I also needed to add "run-time-error" to the root package.json as a dependency because it was accidentally providing that to some sub-packages and when we moved to "run-time-error-cjs" the tests that install plugins from npm started failing (because those releases are still using "run-time-error" and not "run-time-error-cjs") ------------------------------------ Fixes hyperledger-cacti#2807 Fixes hyperledger-cacti#2852 Depends on: hyperledger-cacti#2821 Co-authored-by: Peter Somogyvari <[email protected]> Signed-off-by: Peter Somogyvari <[email protected]> Signed-off-by: Michal Bajer <[email protected]>

@outSH

- Replace deprecated ipfs-http-client with kubo-rpc-client. - kubo-rpc-client must be imported dynamically since it's ESM-only and we still use CJS. Peter's additional changes: --------------------------- build(typescript): project-wide fixes to allow us to use ESM-only deps Apologies for the huge diff, this can't be broken down to smaller changes that would still compile because of cross-package dependencies. I realize that this change is not exactly the optimal solution, but it is probably a step in the right direction. If I somehow found the time to submit pull requests to the libraries that I needed to fork and re-publish (see details below) and then get the changes onto the upstream and get them released as the official packages, then we could (in theory) arrive at a solution that is the recommended way of fixing these problems (apart from going full ESM-only) This work stands on the shoulders of the previous commits from @outSH and takes a slightly different direction compared to what we've been talking about earlier on account of the problem that the eval-import workaround causes crashes in Jest. Based on the above I went through the following adventures: 1. I migrated the build system of kubo-rpc-client myself so that it correctly exports CJS and ESM and typings for both of those as well, I put that code on my fork [1] and then published it onto npm as well [2] After this, I was hoping that now we could just import the package in our CJS code without issues, but what really happened is that instead of crashing at the require call that pull in kubo itself, it started crashing deeper in the require stack where kubo itself was requiring it's own ESM only dependencies (of which there seem to be at least 10 or 15). At this point I realized that me migrating and self-publishing all of these additional packages might not be worth the effort and started looking for something easier. 2. I gave dynamic imports + moduleResultion=Node16 as my next attempt to get our build back to working order. With this, the kubo-rpc-client can now be imported dynamically without issues in packages that declare themselves as resolving modules as "Node16" in their tsconfig.json Other issues here were encountered because not all of our ESM only packages are used in a way that they can be imported dynamically (for example if their types are part of our own types or are being re-exported). The two libraries with this problem were `run-time-error` and `socket.io-client` for both of which I ended up going through the same treatment as for kubo-rpc-client above (but this time my effort wasn't) in vain. They work and so I did some search and replace in the entire codebase to use these re-published packages with the correct types: [3] [4] [5] [6] 3. After this the project build was working, but Jest was still failing with compiler errors which I determined to happen because it uses the root tsconfig.json file for it's internal TS compilation and that root tsconfig.json file was not setting module resolution to Node16. 4. After fixing that the final hurdle (hopefully) was to ensure that jest gets execued with the custom node option as below: NODE_OPTIONS=--experimental-vm-modules yarn jest [1] https://github.com/petermetz/js-kubo-rpc-client-esm-cjs [2] https://www.npmjs.com/package/kubo-rpc-client-esm-cjs [3] https://github.com/petermetz/socket.io-client [4] https://www.npmjs.com/package/socket.io-client-fixed-types [5] https://github.com/petermetz/RuntimeError [6] https://www.npmjs.com/package/run-time-error-cjs Huge thanks for https://arethetypeswrong.github.io/ a tool I used extensively to create the fixes for the libraries above. One more thing that I tried just to collect more data points was to set the moduleResultion project-wide to Node16 via setting it in the root tsconfig.base.json but this broke the compiler itself, as in, there is a bug in the Typescript compiler in v4.x as seen here: microsoft/TypeScript#51221 So this is one more reason for us to upgrade to 5.x as soon as possible. I also needed to add "run-time-error" to the root package.json as a dependency because it was accidentally providing that to some sub-packages and when we moved to "run-time-error-cjs" the tests that install plugins from npm started failing (because those releases are still using "run-time-error" and not "run-time-error-cjs") ------------------------------------ Fixes #2807 Fixes #2852 Depends on: #2821 Co-authored-by: Peter Somogyvari <[email protected]> Signed-off-by: Peter Somogyvari <[email protected]> Signed-off-by: Michal Bajer <[email protected]>

@outSH

- Replace deprecated ipfs-http-client with kubo-rpc-client. - kubo-rpc-client must be imported dynamically since it's ESM-only and we still use CJS. Peter's additional changes: --------------------------- build(typescript): project-wide fixes to allow us to use ESM-only deps Apologies for the huge diff, this can't be broken down to smaller changes that would still compile because of cross-package dependencies. I realize that this change is not exactly the optimal solution, but it is probably a step in the right direction. If I somehow found the time to submit pull requests to the libraries that I needed to fork and re-publish (see details below) and then get the changes onto the upstream and get them released as the official packages, then we could (in theory) arrive at a solution that is the recommended way of fixing these problems (apart from going full ESM-only) This work stands on the shoulders of the previous commits from @outSH and takes a slightly different direction compared to what we've been talking about earlier on account of the problem that the eval-import workaround causes crashes in Jest. Based on the above I went through the following adventures: 1. I migrated the build system of kubo-rpc-client myself so that it correctly exports CJS and ESM and typings for both of those as well, I put that code on my fork [1] and then published it onto npm as well [2] After this, I was hoping that now we could just import the package in our CJS code without issues, but what really happened is that instead of crashing at the require call that pull in kubo itself, it started crashing deeper in the require stack where kubo itself was requiring it's own ESM only dependencies (of which there seem to be at least 10 or 15). At this point I realized that me migrating and self-publishing all of these additional packages might not be worth the effort and started looking for something easier. 2. I gave dynamic imports + moduleResultion=Node16 as my next attempt to get our build back to working order. With this, the kubo-rpc-client can now be imported dynamically without issues in packages that declare themselves as resolving modules as "Node16" in their tsconfig.json Other issues here were encountered because not all of our ESM only packages are used in a way that they can be imported dynamically (for example if their types are part of our own types or are being re-exported). The two libraries with this problem were `run-time-error` and `socket.io-client` for both of which I ended up going through the same treatment as for kubo-rpc-client above (but this time my effort wasn't) in vain. They work and so I did some search and replace in the entire codebase to use these re-published packages with the correct types: [3] [4] [5] [6] 3. After this the project build was working, but Jest was still failing with compiler errors which I determined to happen because it uses the root tsconfig.json file for it's internal TS compilation and that root tsconfig.json file was not setting module resolution to Node16. 4. After fixing that the final hurdle (hopefully) was to ensure that jest gets execued with the custom node option as below: NODE_OPTIONS=--experimental-vm-modules yarn jest [1] https://github.com/petermetz/js-kubo-rpc-client-esm-cjs [2] https://www.npmjs.com/package/kubo-rpc-client-esm-cjs [3] https://github.com/petermetz/socket.io-client [4] https://www.npmjs.com/package/socket.io-client-fixed-types [5] https://github.com/petermetz/RuntimeError [6] https://www.npmjs.com/package/run-time-error-cjs Huge thanks for https://arethetypeswrong.github.io/ a tool I used extensively to create the fixes for the libraries above. One more thing that I tried just to collect more data points was to set the moduleResultion project-wide to Node16 via setting it in the root tsconfig.base.json but this broke the compiler itself, as in, there is a bug in the Typescript compiler in v4.x as seen here: microsoft/TypeScript#51221 So this is one more reason for us to upgrade to 5.x as soon as possible. I also needed to add "run-time-error" to the root package.json as a dependency because it was accidentally providing that to some sub-packages and when we moved to "run-time-error-cjs" the tests that install plugins from npm started failing (because those releases are still using "run-time-error" and not "run-time-error-cjs") ------------------------------------ Fixes hyperledger-cacti#2807 Fixes hyperledger-cacti#2852 Depends on: hyperledger-cacti#2821 Co-authored-by: Peter Somogyvari <[email protected]> Signed-off-by: Peter Somogyvari <[email protected]> Signed-off-by: Michal Bajer <[email protected]>

petermetz requested review from takeutak, izuru0, jagpreetsinghsasan, VRamakrishna and sandeepnRES as code owners October 20, 2023 20:50

petermetz enabled auto-merge (rebase) October 20, 2023 20:50

izuru0 approved these changes Oct 24, 2023

View reviewed changes

outSH mentioned this pull request Oct 24, 2023

build(deps): replace ipfs-http-client with kubo-rpc-client #2829

Merged

5 tasks

jagpreetsinghsasan approved these changes Oct 26, 2023

View reviewed changes

petermetz merged commit 5185968 into hyperledger-cacti:main Oct 26, 2023
92 of 134 checks passed

petermetz deleted the petermetz/issue2807 branch November 30, 2023 01:37

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

build(deps): add resolutions: axios>=0.27.2, nano>=10.0.0 #2821

build(deps): add resolutions: axios>=0.27.2, nano>=10.0.0 #2821

petermetz commented Oct 20, 2023

izuru0 left a comment

jagpreetsinghsasan left a comment

build(deps): add resolutions: axios>=0.27.2, nano>=10.0.0 #2821

build(deps): add resolutions: axios>=0.27.2, nano>=10.0.0 #2821

Conversation

petermetz commented Oct 20, 2023

izuru0 left a comment

Choose a reason for hiding this comment

jagpreetsinghsasan left a comment

Choose a reason for hiding this comment