Any thoughts on when Hyperledger Fabric version 2.4 or 2.4+ will be released on Amazon Managed Blockchain?

When using Hyperledger Fabric v2.2 on Amazon Managed Blockchain, you can use fabric-shim or fabric-contract-api in your chaincode. Here is an example of how to bundle node.js chaincode for use in Amazon Managed Blockchain:

Here are steps for bundling Node.js chaincode with external dependencies, including fabric-contract-api, on Amazon Managed Blockchain Hyperledger Fabric 2.2 networks:

Why bundling is needed: Due to stringent security requirements, peer nodes in Amazon Managed Blockchain do not have access to the open internet. This means that peer nodes cannot download external dependencies at runtime when building/executing chaincode. If you suspect missing node_modules/ are responsible for errors in your chaincode, you can verify this by viewing Chaincode logs in Amazon CloudWatch, where reference to missing node_modules / dependencies will be clearly evident.

How to bundle dependencies First, navigate to the root directory of the chaincode you wish to deploy. Your package.json file should be present in this directory. From this directory, run npm i to install node_modules. Then, move those node_modules to a new directory -- Example:

mv node_modules/ lib

Moving the dependencies to lib/ will allow you to package the installed NPM packages (dependencies) in the chaincode tar.gz file in the following steps. Because the node_modules are stored in lib/, the Node.js start script in package.json has been modified slightly to tell the container environment that runs the chaincode where to find the dependencies at runtime: "start": "NODE_PATH=lib node <entrypoint filename>.js"

{
  "name": "chaincode",
  "version": "1.0.0",
  "scripts": {
    "test": "NODE_PATH=lib mocha *_test.js",
    "start": "NODE_PATH=lib node products.js"
  },
  "dependencies": {
    "fabric-shim": "^2.0.0"
  },
  "devDependencies": {
    "@theledger/fabric-mock-stub": "^2.0.3",
    "chai": "^4.2.0",
    "chai-as-promised": "^7.1.1",
    "chai-datetime": "^1.6.0",
    "moment": "^2.25.3"
  }
}

With the node_modules bundled in lib/ and the start script for the chaincode modified to point to those node_modules, one can now package, install, approve and commit this chaincode as normal using the Chaincode Lifecycle commands.

UPDATE: April 14 2023 Working with fabric-contract-api

For Javascript chaincode, manually bundling and defining a path to those dependencies is a viable workaround when using fabric-shim, the lower-level chaincode interface. However, when using the higher-level fabric-contract-api, a custom startup script is required to properly initialize the chaincode (fabric chaincode-node start). This custom startup script is incompatible with the aforementioned workaround for manually bundling dependencies for Node.js (Javascript) chaincode, as it overrides the custom NODE_PATH for chaincode dependencies.

In order to successfully build, package and deploy chaincode that depends on fabric-contract-apior chaincode that uses Typescript as its implementation language, you must manually package chaincode in the standard tar.gz format with the node_modules folder intact. This renders a chaincode package that is the same format as what the peer lifecycle chaincode package command creates, but with node_modules and dist/ folders in place.

A sample bash script (not to be used in production) shows how to manually package chaincode, which is intended to be used after running npm install and/or npm run build if applicable. This bash script is designed to package a chaincode directory that is implemented in typescript, which already has the source code in a directory, src/:

#!/bin/bash
#set home directory
home_dir=$HOME
echo "Your home directory is $home_dir"

# Ask the user for chaincode details
read -p 'Enter your chaincode package name (e.g. chaincode_1.0):' chaincode_name
read -p 'Enter your chaincode languade (e.g. node, java, go):' chaincode_lang
read -p 'Enter the path to your chaincode:' chaincode_path
echo

#create directory name for chaincode
cd
chaincode_dir="$chaincode_name""$chaincode_lang"
mkdir "$chaincode_dir"

#create metadata.json file
cd
cd "$chaincode_dir"
chaincode_dir_path=$PWD
echo "chaincode package building at $chaincode_dir_path"
cat <<EOT > metadata.json
{"path":"$chaincode_path","type":"$chaincode_lang","label":"$chaincode_name"}
EOT
mkdir src

#copy code from user provided chaincode path to chaincode directory
cp -r "$chaincode_path""/." "$chaincode_dir_path""/src" 

#tar the code in src/, then tar the whole chaincode directory
tar -czf code.tar.gz "src/"
rm -r src
cd
find "$chaincode_dir_path" -printf "%P\n" | tar -czf "$chaincode_name".tar.gz --no-recursion -C "$chaincode_dir_path" -T -     

With this chaincode package manually created, you can install, approve, and commit the chaincode as normal. You can modify the above bash script to handle any type of chaincode directory structure. Your target package structure is as follows:

<chaincode-package-name>.tar.gz/
├─ code.tar.gz/
│  ├─ src/
├─ metadata.json

Your entire source code directory, including node_modulesand dist directories, will be archived in code.tar.gz within a directory called src. A metadata.json file containing the path, chaincode runtime and chaincode name will also be created. Both code.tar.gz and metadata.json will then be archived in a tar.gz file named the same as the chaincode name.