You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Node.js chaincode build containers require access to the npm registry when installing chaincode.
This becomes an issue for peers that are "offline" (e.g. peers from cloud providers) and do not have access to the npm registry. Simply running "npm install" before packaging chaincode with "peer lifecycle package" does not solve the problem alone, since the package command ignores the node_modules directory.
We have identified two possible ways to solve this:
Creating the tarball package manually without using "peer lifecycle package".
Bundling the application (e.g. with esbuild) before packaging it with "peer lifecycle package".
While the first option works fine, it does make the process of deploying Node.js chaincode a lot more complex than deploying Go or Java chaincode. We would therefore prefer the second option, however, we are still required to add fabric-shim as a module outside the bundle, so that "fabric-chaincode-node start" is available when bootstrapping the chaincode.
Would it be possible to start the application without requiring "fabric-chaincode-node start" as an external script, e.g. by calling the bootstrap function in the chaincode's index.js instead?
Are there any other simple ways to solve this that I've missed or is manually creating the tarball the suggested approach for now?
This issue was also discussed in #197 but seems unresolved
The text was updated successfully, but these errors were encountered:
Thanks @jt-nti , resources on Hyperledger Fabric "best practices" are very appreciated. However, I don't think the proposed solutions will work for peers issued through cloud providers as one will typically not be able to manage the peer containers directly, i.e. it will not be possible to add local repositories and we do not control the chaincode container deployment.
I know this problem is more of a cloud provider issue, but from our point of view this process would be a lot simpler if we would be able to "bootstrap" the chaincode inside Node.js (e.g. in index.js) without requiring the "fabric-chaincode-node start" script to be called. I assume this is not possible in the current version of the chaincode library? I don't know the effort that would be required to make this possible in future releases, but I would suggest bringing this up for consideration.
Node.js chaincode build containers require access to the npm registry when installing chaincode.
This becomes an issue for peers that are "offline" (e.g. peers from cloud providers) and do not have access to the npm registry. Simply running "npm install" before packaging chaincode with "peer lifecycle package" does not solve the problem alone, since the package command ignores the node_modules directory.
We have identified two possible ways to solve this:
While the first option works fine, it does make the process of deploying Node.js chaincode a lot more complex than deploying Go or Java chaincode. We would therefore prefer the second option, however, we are still required to add fabric-shim as a module outside the bundle, so that "fabric-chaincode-node start" is available when bootstrapping the chaincode.
Would it be possible to start the application without requiring "fabric-chaincode-node start" as an external script, e.g. by calling the bootstrap function in the chaincode's index.js instead?
Are there any other simple ways to solve this that I've missed or is manually creating the tarball the suggested approach for now?
This issue was also discussed in #197 but seems unresolved
The text was updated successfully, but these errors were encountered: