Design for now
Playback of what we could do and evaluate as an option

A group of tests can be run e.g. all the tests under a nested describe

Most likely a testing story only; ensure that a smart contract project in JavaScript and Golang has syntax highlighting for the smart contract code. This should be provided by the extensions for the respective programming languages, but those plugins might not be installed out of the box - what happens in this case? Do we need to add documentation to say if you want to write smart contracts in Golang, you must first install the Golang extension?

There is enough info in the skeleton test file that a user can update it to tests their specific functions

Can we use the Fabric in development mode to do this?
Can we get the existing programming language extension debug functionality to start the chaincode to connect to a Fabric in development mode?

in createSmartContractProjectCommands.ts, at the point where it runs yo fabric:chaincode to determine available chaincode languages, add in a progress/loading box so the user knows to wait (there's one implemented in the grpc/dependency code)

As well as being searchable from within VSCode's extensions catalog, published extensions appear in a web marketplace.

The Docker extension is a good example of how these can look:
https://marketplace.visualstudio.com/items?itemName=PeterJausovec.vscode-docker

The top of the page features the extension icon and a banner colour (already mentioned in #34 ). Below that is a kind of single-page documentation for the extension. The docker one bullet-points some key benefits, then has sections for each of the features that installing it will add to VSCode complete with a selection of looping videos and screenshots.

I'd like us to start working on the catalog page for our extension. Firstly because we're going to need one, and secondly because if we describe what we're planning for it to be in this way then we can show it to people and say "would you download this? If not, what else would you be looking for?" etc.to validate whether we're making an extension folks will want to use!

Before we publish the extension, the GitHub readme seems a great place to do this work. In fact, just look at the GitHub readme for the Docker extension:
https://github.com/microsoft/vscode-docker
(Spoiler: it looks the same as the marketplace page!)

Let's include the highest fidelity we have for anything we want to show in there e.g. if we talk about the "start a new Fabric chaincode project" bit, we could include a video of this actually happening since @Heatherp has already got an implementation of that bit :)
Meanwhile if we're talking about automatically spinning up the local_fabric connection, we could include a screenshot from @simran-sohanpal 's latest mockups.

I'd like us to create the page now, then update it as the project continues - it'll also form an excellent basis to give us a headstart on writing the docs once we know where they are going to live.

"Test view" that exposes the functions available
Enter arguments
Use code lens to allow execution of each function
View results of each function

Notes:

• should function in the same way as the view created in #4 (?)
• usefulness to be determined in Phase 2 after we've had some user feedback.
• potentially not needed if "created smart contract package" notification implemented in #2 works well
• quick mock up below:

How do bugs/issues with the Fabric extension get reported and routed into the engineering team?

Most likely a testing story only; ensure that a smart contract project in JavaScript and Golang has code completion for the smart contract code. This should be provided by the extensions for the respective programming languages, but those plugins might not be installed out of the box - what happens in this case? Do we need to add documentation to say if you want to write smart contracts in Golang, you must first install the Golang extension?

Also, might require updates on Fabric itself. For example, VS Code will not provide code completion for the fabric-shim module unless it provides a Typescript definition file for those APIs. This team might need to add those into Fabric to enable this functionality.

• Select from packages in the directory
• (or specify another path??)

If while creating a connection the user decides to cancel they can then carry on where they left off. The half created connection will appear in the list but will have appropriate icons to show that it is not complete and it won't let the user connect until it is complete

Suggested phase 1 behaviour is that abandoning part way through will mean the Connection does not get created (they start again if they want to continue creating it).

Pick from packages in package view
Automatically do install on any peers they own
Then do the instantiate on the channel

Leave til Phase 2 - needs more thought

npm view generator-fabric version checks npmjs.org to see if the specified package exists, and then returns the latest version of that package. It does not actually check to see if the specified package is installed locally, or if it's the right version - and we need to do both!

npm ls -g --depth=0 generator-fabric will check to see if the specified package is installed locally. We also need to check if it's of a version that is compatible with the extension, e.g. the work in issue #51 will require [email protected] or greater to be installed. We will need to prompt the user that they must upgrade their installed version if this is the case.

Where do we put this tutorial

Set of tasks in documentation:

Start a new project
Create package
View, Edit, Delete packages
Add a connection
Automatic local Fabric
Specific connection
Remove a connection
Use a connection
Understand the resource tree of a network
Install a smart contract to a peer (using a package)
Instantiate a smart contract on a channel
Test the functions in a deployed smart contract

This is because we pass the argument --name="new-smart-contract" to the Yeoman generator; we should use the name of the directory that the project is being created in instead!

A developer can right click on instantiated chaincode and it will generate a test file that has all the skeleton code needed to run integration tests
e.g

describe('myContract', () => {
   before(() => {
        \\ connect to a client based on the connection details from the connection they chose
    });

    describe('myFunction', () => {
         it('should do something useful', () => {
              assert('something', 'something');
         });
    });
});

Epic to collect together issues that are part of making the extension available and understandable (e.g. things related to readmes, store pages, docs etc. etc.)

Packages view allows a package to be deleted in IDE.
Removing the folder from the configured storage location also has the same effect.

From the current low-fis:

Opens the source project for editing, only if the source project is available on the users workspace/system (as opposed to editing a package that someone gave to me that I do not have the source for).

From current low-fis:

This would mean we need info about where it "came from"... Which does feel kind of weird. Need more thought & discussion to decide whether we want to do this.

A user can run a command and it will take the currently active project and copy the files into a folder e.g. ~/.fabric-vscode. This folder should be configurable in the user settings and should read the updated settings when creating the package.

Once a user has generated tests and then saved it in their project and packaged it and installed and instantiated it, they will have the option to right click and run the tests which were previously generated

A developer opening a project that was created using the Fabric VSCode extension should have it suggested that they install said extension if they don't already have it.

(There is apparently a file that can do this!)

We need a better story about why this makes sense! But probably not Phase 1 anyhow.

Dev should be able to go to the extensions catalog in VSCode...

Search for "fabric"...

And find our blockchain extension! Then install it. And they should probably be able to find it via their browser too!

A button on the package view that lets you select a folder to add to the package view (later this will be an actual package)

From the current low-fis:

npm view generator-fabric version returns the latest available version, npm ls -g generator-fabric | grep . returns the globally installed version, fix this in createSmartContractProjectCommand.ts
add a check for ensuring the user has the latest version of generator-fabric (and yo?), update it if they haven't

Select from smart contracts on the peers

The new project window should open after Yeoman generator has completed, because otherwise you get a couple of seconds of looking at an empty new project window until the code turns up.

All tests in a test file can be run

Just a single test in a test file can be run

Reference documentation

Commands so far....

Add Connection
Delete Connection
Add Identity To Connection
Create Project

Possible candidate to roll into the ReadMe and other docs issue

How we enable translation of the Fabric extension, so it can be used in Chinese, Spanish, Pirate?

If we put the infrastructure in place to enable this, then we could potentially crowd source the translations from the community, or try to get some IBM translation budget.

window's features (e.g. outputChannel or terminal) only accessible via first window
Found during implementing #1
Tried:

openFolder (current implementation, with new window flag set to true)
updateWorkspaceFolders - errors because fabric project isn't a workspace
Probably not fixable because vscode API doesn't allow you to cycle through windows.

Next to try:

making the new window an activation event of the extension
look at alternative activation events once the folder's opened: https://code.visualstudio.com/docs/extensionAPI/activation-events#_activationeventsworkspacecontains
looking at https://code.visualstudio.com/docs/extensionAPI/vscode-api#ExtensionContext and globalState/workplaceState
look at: https://code.visualstudio.com/updates/v1_26#_uri-handler-api

As part of the release process through travis the extension is publish to the vscode market place

Original content:

• If they go to add a connection, check whether they have a local Fabric running.
• If not, offer to create one.
• Connection name, connection profile, cert, public key can all be automatically set/generated

Update from @EdMoffatt

Low-fi here:

https://xd.adobe.com/view/0bd1f7aa-4358-4526-550b-841b4ba2c81f-7de0/

This is suggesting that ideally we'd like everything to just happen automagically ;) . The logic of what's happening behind the scenes is:

• Detect that the Fabric docker images that would be running if a local fabric were available aren't there, AND there's no local_fabric connection already configured
• In that case, offer the option to auto-configure a local_fabric connection
• When selected, this will pull down the images, start them up, name a new connection local_fabric, generate a connection profile, certificate and private key for it, and use those to complete the connection

One thing we'll need to consider is that this will probably take quite a while to happen! Is there any established convention for operations that take a while once started and don't require any user intervention?

The level of simplicity shown in the lowfi is probably skipping out too much detail, but it gives something to start looking into!

Linked to #26 how do we debug bugs/issues with the Fabric extension? What logs and reproduce material do we need to collect, and how do we ensure this is collected?