ibm-blockchain / generator-fabric Goto Github PK

Allow an application to easily require the generator class.

Add a new contract generator, which can generate JavaScript contracts for Fabric v1.3 using the new smart contracts with transaction functions being delivered under FAB-11246.

Add a new contract generator, which can generate Go contracts for Fabric v1.4 (?) using the new smart contracts with transaction functions being delivered under FAB-11246.

The interfaces and basic implementation are now in the fabric-chaincode-java master branch. So worth following this with a sample contract in the generator.

With the ability in the upcoming 1.4.1 contract api, the context needs updating to support the contract level logging capabiliites.

A tx function can now use a standard logger class to route it's output, as well as control log levels. It allows devs to move away from the 'console.log' style of debugging.

Generator work for this VSCode issue:
IBM-Blockchain/blockchain-vscode-extension#776

In order to get service discovery working with the local Fabric, we need to both dynamically assign ports for the local Fabric, then edit the configtx.yaml configuration (to set the correct endpoints for the orderer and the anchor peers), and then regenerate the crypto-config and config transactions/blocks.

This requires a bunch of search/replace in files that would be better placed in the Yeoman generator, rather than within the VSCode codebase.

The plan is to add a fabric:network subgenerator that VSCode can use to generate a 1 organisation, 1 peer local Fabric network which is correctly configured for service discovery.

Turns out choice is a poor replacement for sleep, so instead use Node.js to do a one second sleep: node -e "setTimeout(() => true, 1000)".

In a recent CR delivered into Fabric v1.3, the startChaincode command was renamed to fabric-chaincode-node start, so we need to update the generated package.json files accordingly.

If you use the license option, it does not create the correct license headers. Instead, you always get the Apache-2.0 license in your generated chaincode or contracts.

Specifically, the code generated cannot find fabric-shim, for example in the my-contract.spec.tx file

Is this a known issue or have I done something silly?

We need to add the following parameters to a default generated TypeScript smart contract:

"preLaunchTask": "tsc: build - tsconfig.json",
"outFiles": [
    "${workspaceFolder}/dist/**/*.js"
]

When you run the generator inside a tool like Visual Studio Code, the project will instantly show errors until the dependencies are manually installed using npm install. The Yeoman documentation strongly suggests that you should install the dependencies for the users as part of the generator:
http://yeoman.io/authoring/dependencies.html

Will extend the generator to run npm install automatically for both the chaincode and contract subgenerators.

update is running to check a smart contract container

If the generate.sh script of a network fails midway, for example during configtxgen, or if the user deletes all Docker containers (but not volumes) and file system data - the is_generated.sh script returns 0, but the network cannot possibly start.

We need to update the generate.sh script such that:

• It performs a teardown at the start to clean up whatever is around
• It touches a generate.complete file at the end

We need to update the is_generated.sh script such that:

• It checks for the generate.complete file, and returns 1 if it does not exist

the tests are generated like

            String json = "{\"value\":\"TheAsset\"}";

            contract.createPenguin(ctx, "10001", "TheAsset");

could TheAsset be whatever type of asset you create e.g. ThePenguin

As part of the continuous integration build, we should add the languages supported by the generator-fabric to the package.json file. This will allow quick retrieval of supported languages from external systems.

The generator should detect when it is being used by the VSCode extension. If so, the generator should use a custom Yeoman Conflicter to provide a VSCode extension user information about file conflicts and should be able to handle any responses.

Generated Go projects should recommend the Go extensions, and generated Java projects should recommend the Java extensions - this will help ensure the extensions are available when the user tries to debug the generated project using the IBM Blockchain Platform extension for VS Code.

• The build should fail if npm audit finds any vulnerabilities

• We should check in the package-lock.json file as per the official guidance from npm:

https://docs.npmjs.com/files/package-locks#using-locked-packages

It is highly recommended you commit the generated package lock to source control: this will allow anyone else on your team, your deployments, your CI/continuous integration, and anyone else who runs npm install in your package source to get the exact same dependency tree that you were developing on. Additionally, the diffs from these changes are human-readable and will inform you of any changes npm has made to your node_modules, so you can notice if any transitive dependencies were updated, hoisted, etc.

This will stop us being taken out by breaking downstream package changes such as the recent changes to the sinon module.

• We should run npm shrinkwrap before publishing the code.

Allow the generated fabric network to be 1.4.x or 2.0

Generator changes needed for 2.0:

• update docker compose file to change 1.4.1 to 2.0
• update generator.sh and generator.cmd to change 1.4.1 to 2.0
• add ordererchannel in orderer genesis block thing in generator.sh and generator.cmd

In the tsconfig file source maps should be set to true to enable debugging

Add a new contract generator, which can generate TypeScript contracts for Fabric v1.3 using the new smart contracts with transaction functions being delivered under FAB-11246.

in here, and in npm (which I assume just reads the README?): https://www.npmjs.com/package/generator-fabric

Add in capabilities to config to allow private data collections

The integration tests currently only cover the JavaScript and TypeScript chaincode generators, they should also cover the Go chaincode generator as well. I only left it out the first time round because I'm too lazy to add some if blocks.

At the moment, there is no validation for user input (both running the generator normally and passing arguments to the command). It would be beneficial to validate user input, as it would prevent errors from occurring.

The generator needs to be upgraded to Fabric v1.3, so that we can begin work on implementing a smart contract generator for the new smart contracts with transaction functions being delivered under FAB-11246.

I propose that we separate chaincode and contract generator for now, as Go support for contracts will not be delivered until Fabric v1.4 (and people may want to use the old style contracts).