The workspace info is quite useful. It could be even better if the dependencies of a piral app shell would link to their README pages.

This could open a webview in VS Code to give some direct insight how to use the plugin.

Since the Piral CLI supports *.codegen files the Piral VS Code extension should bring this support, too.

In the end a codegen file is just a JS file. Maybe have one snippet ("export"?) to support scaffolding codegen files quickly.

Introduce a visual scaffold helper / page.

Could be similar to the one shown for Rax VS Code Extension, specifically create.

Right now we only allow the selection of a bundler, but the piral-cli can do more.

We should allow the selection of:

• auto (automatically detects uses the right client, falls back to npm)
• npm
• yarn
• pnpm

The design should be the same as for the bundlers (i.e., have a nice logo for each).

Populate the Piral workspace info with useful information:

• Is the currently opened folder a monorepo, piral, or pilet workspace?
• What is the app shell (incl. version of the app shell)?
• What version of the Piral CLI is used?
• Is this the latest version of the app shell?
• Is this the latest version of the Piral CLI?
• What plugins are used (for the app shell)?
• What dependencies are shared (for a pilet)?

Right now the trigger point for identifying projects does not know about "pilet.json" and "piral.json". Therefore, e.g., pilets that are created using the new method (pilet.json) and don't have an "piral" field in their package.json will not be usable with the VS Code extension.

We should update the extension to also allow this new way.

It should be quite cool to be able to log into (different, i.e., the public one/s as well as private / on-premise instances of) the Piral Feed Service.

VS Code can safely store the retrieved token allowing a personalized session that could be used to interact with the feed(s) such as changing rules, toggling pilets, ... - or having the interactive publish done very conveniently (w/o even logging in as one is already logged in).

See:
https://github.com/microsoft/vscode-extension-samples/blob/main/authenticationprovider-sample/README.md

The VS Code extension provides available commands for Piral or Pilets.

The available commands currently used reference the global installation of the piral-cli.
Since using the local piral-cli is recommended, also the commands inside the VS Code extension shall be adapted.
This basically means that the command
piral <parameter>
shall be substituted with
npx piral <parameter>.

Before a command is executed, it shall be validated that the piral-cli is locally available. This can be done by checking whether the node_modules/.bin/piral or pilet reference is available.

If the local piral-cli is not available, the user shall be notified to perform npm i to install the required dependencies, or the user will be informed and asked whether the missing dependencies shall be installed, and the command will be performed afterward.

If the local piral-cli is available, the command shall be performed.

Acceptance Criteria:

• Every time the user invokes one of the available commands, the command is performed or in case of an error, the user will be guided to solve the problem.
• Define and perform test cases (e.g. Piral Cli is not locally available, ...).

In continuation of the previous issue #13 we want to take this a step further.

Improvements

1. Add More Bundlers
2. Split Into More Pages
3. Support Templates
4. Support Dynamic Options

Let's go into the details.

1. Add More Bundlers

For the moment we can leave this dynamic. Right now we have

• webpack
• parcel

We should also add:

• webpack5
• parcel2
• rollup
• vite
• esbuild
• xbuild

You'll find an image / logo for all of these (except xbuild) on the Internet. For xbuild just use a logo as for "script" / "computer" or whatever.

The choice of bundler will impact the --bundler option; usually there is nothing here to do - just forward the selected option.

2. Split Into More Pages

The flow should be:

1. Overview page; select "Piral instance" vs "pilet" and the template (see 3)
2. Must press "Next"
3. Select options for the given mode (Piral instance / pilet) and template (see 4); here we also select the location
4. Either press "Finish" or go back via "Previous"

3. Support Templates

We should load available templates from the Internet. Right now I am not sure if we should just leverage npm:

• GET to https://registry.npmjs.org/-/v1/search?text=keywords:pilet+template&size=250 for the pilet templates
• GET to https://registry.npmjs.org/-/v1/search?text=keywords:piral+template&size=250 for the piral templates

I'll be thinking about a good way to communicate some meta here (e.g., preview image, options, ...).

4. Support Dynamic Options

Some templates support additional options. For instance, the default template (@smapiot/piral-template-default) supports title for naming the document etc. - we should show these option fields (and maybe pre-populate with their default values).

Right now I am not sure how this can be best done (we would need to reflect on the used template, best way is maybe via the npm meta data). I'll be thinking about how it can be done and update the post.

Requirements

• All the improvements have been implemented
• The dialog is split into multiple pages
• The dialog works as expected
• Lazy loading (e.g., of available templates) is indicated via a loading indicator
• The whole setup is responsive
• Error cases such as npm API not responding are handling gracefully (e.g., we have two templates always available; empty and default)

Acceptance Criteria

• All requirements fulfilled
• User experience is as expected
• Coding standards are fulfilled
• Separation of concerns and re-usability was respected
• New templates can be added / are supported

cc @iotcloudarchitect

We should introduce some VS Code tasks for debugging Piral instances or pilets.

It is yet unclear if we can use the same for piral-cli-parcel and piral-cli-webpack. Maybe distinguish for now?

• A potential Parcel config
• A primer for Webpack
• Task provider in a VS Code extension

https://code.visualstudio.com/api/extension-guides/debugger-extension

The current webview of the "Create Project" dialog shall be redesigned and standard UI components shall be utilized.

The following example gives an impression of the expectation regarding the layout and look&feel (RAX extension):

It would also be good to substitute the folder selection in the very beginning of the user flow

Acceptance Criteria

• Fully responsive - in case the webview is resized, it remains fully functional
• UI elements from Webview UI Toolkit for Visual Studio Code are used and substituted the currently used ones
• Standard fonts, sizes, colors etc. shall be utilized (i.e. no smapiot green)

We might want to add a plugin for webstorm.

See https://plugins.jetbrains.com/docs/intellij/webstorm.html

We could link the documentation page of the CLI / Piral in the workspace info.

This is similar to #10, however, instead of showing the README (e.g., from GitHub or NPM) we show the docs.piral.io page.

Ideal case: We show the documentation for the specific version.

We should populate the navigation bar list with some useful commands:

• Build Piral (or pilet)
• Debug Piral (or pilet)
• Debug pilets (if monorepo)
• Validate Piral (or pilet)
• Any other piral / pilet commands found in the workspace's package.json

Right now we have some problems with the local path input element.

As visible, the paths overlap with the icon. This looks strange. The icon should always be on top here and not interfere with the text below. That one should be padded accordingly.

Also, the input element is always readonly. This makes it impossible to give it a new folder. Instead, only existing folders can be selected (which, honestly, would be OK if I could edit the path / append the folder later on).

Finally, the text boxes are not wide enough. We got plenty of screen space.

Maybe the last points can all be tackled in the context of #15.

Problem
The extensions is not able to load the workspace. In src/extension.ts on line 23, workspace.uri.path returns the path prefixed with '/'.

VS Code Error
Could not load the "package.json". Make sure the workspace is valid.

Potential Fix
In src/extension.ts on line 23, replace workspace.uri.path with workspace.uri.fsPath.

Platform
Version: 1.46.1 (user setup)
Commit: cd9ea6488829f560dc949a8b2fb789f3cdc05f5d
Date: 2020-06-17T21:13:20.174Z
Electron: 7.3.1
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Windows_NT x64 10.0.17763