To support selection of a credential profile from a picker we need functionality that can:

• Read and parse the shared credentials file and maintain a list of profile names.
• Establish a watch on the file and self-update the available profiles when the file is changed.

Questions to resolve:

• what should happen if the currently bound profile is deleted from the file?

Needs to explain the working process, what we expect in pull requests, the definition of 'done' etc. Sharing the JetBrains definitions seems sensible.

Right click on a region should offer a context menu invoking the remove region command.

We'll use this as input to the design of the packaging and deployment subsystems. The investigation needs to also document how we will detect the current code is a Python Lambda function.

Work on this issue needs to be in conjunction with the overall design of our packaging and deployment subsystem detailed in issue #8.

This will require issue #2 to be completed first.

When the aws.login command is triggered we will display a drop-down picker of available credential profiles. The picker will list the available profile names, together with a pseudo entry allowing entry of data for a new profile. To support selection of an existing profile or entry of a new one we will base the picker of the new multi-step picker APIs.

If the user selects an existing profile we will transition to the final workflow state and update the current context to bind to the new profile. This in turn fires an event so the Explorer and status bar update.

If the user selects the 'create new' entry we transition to a series of states that prompt the user to enter the access key, secret key and finally a name for the profile. The new profile will be automatically selected for use which will complete the workflow and fire the necessary events, the same as if an existing profile had been selected.

If the user has no profiles when the command is invoked the picker will automatically transition into the data entry states to have the user enter the necessary data.

From an extension point of view we want to hand off packaging and deployment to underlying language specific 'engines' (similar to how we handle web site vs web app projects in the Visual Studio toolkit). The user will invoke a single command (eg aws.packageLambda and aws.deployLambda), they will query the workspace to determine the language in use and hand off to the correct engine as appropriate.

For example, when packaging (and deploying) C# functions we'll want to delegate to our .NET CLI extension tooling. For functions in Node.js we'll want to do something else (for both packaging and deployment). And so on. At time of raising this issue we envisage the languages we need to support as being Node.js, Python and C#.

This issue is to design and document (in the repo) the interfaces to these engines so that they can be implemented.

As part of the definition of 'done' we need to record a video demo of how we manage regions in the explorer and create a one-page summary doc of the feature that can be used by doc teams in the preparation of user guide materials.

Requires completion of the region management issues.

How we can hook into the Python / Node subsystems to allow us to debug Lambda:

Output: a brown-bag for how this might work and an initial backlog of issues to work on.

Debug extensibility for VSCode is documented here.

• Ensure profile data is loaded from config and credentials
• profile properties that exist in both files should use the value from credentials
• Add (and document) an extension Preference that can load from, or ignore the config file
  • Default to loading from file
  • involves env var AWS_SDK_LOAD_CONFIG
  • See https://github.com/aws/aws-sdk-js/blob/master/CHANGELOG.md#2440

In some places, we still use then where async/await would be more clear. We shouldn't have "legacy" code at this early stage of development. We should give the existing codebase a once-over to make sure that we're using async/await.

We'll make use of the build script from issue #18 in this infrastructure. The build infrastructure should deliver the built .vsix to a location we can consume in downstream test and release pipelines.

We want users to be able to create new Lambda functions (and potentially serverless apps?) from within VS Code using a command gesture or button on the Explorer. The resulting workflow will need to guide users through selecting a template (also known as a blueprint in Visual Studio toolkit) appropriate to what they want to build and deploy and the host language.

This issue is to design the workflow and UI experience and will yield additional issues for implementation upon sign-off.

For example we could:

• Implement a multi-step picker that first narrows the selection down to a function or an app, then lists the available languages for the respective templates, then on selection displays a webview panel detailing the available templates
• or, we could have the command gesture launch a webview with filtering controls allowing the selection refinement process.

In either case, the webview should be structured such that clicking on a template fills out a panel with more details of what the template outputs and what it can be used for, plus any other relevant information (eg permissions required for it to work perhaps). A button on that panel will then allow the user to cause the project (workspace) to be generated from the template and VSCode then instructed to open it. We may also want an option to have the user elect to have the folder containing the generated project be added to the current workspace.

This might be contentious :-)

When the user defines a new credential profile as part of the picker experience noted in issue #3 we need to persist it somewhere. The logical place is back to the shared credential file so it's available for other tools.

To accompany the video demo in issue #3, create a one page doc summary of the credential management support that can be handed off to doc teams for use in user guide preparation.

Requires completion of the credential management issues.

We currently read and parse the credentials file when the user invokes the aws.login command, which is not a time sensitive operation. From the perspective of populating the dropdown list of profiles we don't therefore necessarily need to cache.

Where a file watch is helpful is in when the user deletes a profile we currently have bound in the explorer and views - although we have sdk clients instantiated in those views, view refresh logic may try and instantiate new clients with the now-deleted profile name and fail.

We need to determine the level of caching and file watch needed (current profiles only? all profiles?) and implement, with tests that we can instantiate fresh sdk clients (or error out nicely) if the user deletes an in-use profile.

As part of the definition of 'done' we need to record a video demo of how we manage credentials and create a one-page summary doc of the feature that can be used by doc teams in the preparation of user guide materials.

Requires completion of the credential management features.

Currently the readme just details the repository name and intent, which is not very welcoming!

Take a look at the VSTS one for inspiration.

We want to keep some workspace-local metadata that maps the user's code to deployed Lambda functions (and serverless apps). This is the 'app model' file concept that's been floated around and is similar in concept to the Cloud9 .application.json file.

This task is to design what we'll do in VSCode. Output will be a design doc for discussion and one or more tasks for implementation.

• Can we re-use the Cloud9 file (and perhaps the jetBrains version, if it should exist)? How do we keep in sync with them if so?
• Do we need our own file? If so, what's the format and what's the round trip story with Cloud9?

I'm sure other issues and considerations will come forward when we start to think this through more deeply!

To accompany the video demo in issue #25, create a one page doc summary of the region management support that can be handed off to doc teams for use in user guide preparation.

Requires completion of the region management issues.

When regions are added to the explorer we currently fire an event containing the region code, which is then displayed as the node text. Displaying the region name (maybe with the code in [] afterwards for users who care) is a friendlier approach.

Instead of including only the region code in the event, consider using the RegionInfo type we get from parsing the endpoints file which will be available from cached data when issue #30 is completed. It carries code and name.

On load of persisted region settings we'll also need an api to lookup the region code in the cached endpoint data.

Credential profiles that use assume role and MFA should prompt the user for the MFA token in the Toolkit.
All Service clients should use the resulting credentials unless closes VS Code.

Requires issue #12 to be completed first.

We'll use this as input to the design of the packaging and deployment subsystems. The investigation needs to also document how we will detect the current code is a Node.js Lambda function.

Work on this issue needs to be in conjunction with the overall design of our packaging and deployment subsystem detailed in issue #8.

JetBrains example format : "AWS-Toolkit-For-JetBrains/${AwsToolkit.PLUGIN_VERSION} $platformName/$platformVersion"

See commit : aws/aws-toolkit-jetbrains@c59ecaa

• Do we write to the credential file? #5
• Do we want to watch for credential file changes ? #37
• What if the file does not exist?

This is an issue to define how to integrate a MVP user feedback (for issues or general feedback) gesture into the tool. Once the requirements and design are signed off we will create new issues from it for implementation.

Current MVP proposal is to use a button/command gesture that opens a browser onto our GitHub repo's new issue page. We would provide a nicely formatted template for the user to complete:

a) If they are logged in it is almost seamless,
b) if they have an account it is reasonable,
c) if they do not yet have an account, then we are encouraging them to become part of the community :-)

Other experiences may be possible in future, for now we'll stick to a GitHub based MVP for design purposes.

Currently we download/read the file every time we need it (with fallback to a version in the extension if the download fails). Ideally we want to parse this file once per startup (however we get it) and keep the parsed results cached in the RegionHelper class.

For development we can use the npm watch tasks defined in the workspace. However for release to the marketplace we need a build script/make file that can produce a digitally signed .vsix extension file that we can upload.

Note digitally signing isn't (so far as we know right now) a requirement for the marketplace, but we should do it anyway for customer assurance - same as we do for the VSTS tools.

The build script needs to run headless so we can have it running 24x7 in CodeBuild, triggered from commits.

I've been using https://marketplace.visualstudio.com/items?itemName=DavidAnson.vscode-markdownlint to check my markdown changes, but that only affects me. Instead we should integrate markdownlint into the npm run lint script so that all devs see the warnings.

For now, set up a simple telemetry logger. In the future, we can add event batching, and offline caching.

• Set up project to log telemetry
  • Bring the current swagger definition of the Telemetry Client into the repo
    • service client is obtained by passing this into the AWS JS SDK
  • Create retriever to get credentials from Cognito for use with telemetry service
  • Set up configuration to provide the Cognito poolId and telemetry service url
• Log basic telemetry datapoints
  • extension Initialization (toolkit version, telemetry client version, initialization duration)
  • aws lambda invoke
  • aws lambda invoke result (success/failure)
  • refer to the (internal) document of prioritized metrics to start with

We want the Explorer panel for Lambda to be able to show available functions across one or more regions but without the overhead of querying all AWS regions on startup. Putting the user in control of what regions they want to work with in a given workspace seems a reasonable compromise.

This work will involve:

• Two new command gestures to enable users to register regions they want listed and to remove regions.
• Updating the current region setting persistence to serialize and deserialize as a comma-delimited list.
• When the Explorer opens, if no region data is available from the workspace it will display a node inviting the user to click and select an initial region (launches the add region command)
• Updating the Explorer to show all selected regions; if functions are available in a region they are displayed as child nodes. If no functions are available the Explorer will display a node with text to that effect.

If the user selects to add a profile in the Toolkit:

• If user has no config or credentials files, prompt user, and generate one from a template
  • Prompts: Profile name, access key, secret key
  • Explain to the user how this information will be used
  • template file contains useful comments explaining parts of the file and/or where to get more information about the file online
• If the user does have these files, open credentials in the editor, and show them information (a webpage) about how to work with this file
• If there are no profiles to select from when user tries to sign in, the UI should inform the user that there are no profiles, and provide them with the option of adding a new profile, which then follows as described above.

We don't have much logging yet, but the logging that we do have writes directly to console. We should decide on a logging framework instead.

After installation from the marketplace we want to invite the user to explore the capabilities of the toolkit and potentially include a gesture to set up initial credentials etc. Some extensions use a subtle pop-up window in the lower right to welcome the user, or invite the user to view details of an update. For updates some extensions display a nicely formatted webview (I'm thinking GitLens here).

This issue is to define what we want to do and will spawn additional refinement issues for the implementation.

Want a two column upper (sample request fields on left, response field on right) with the log output in a bottom row spanning both columns - similar to the VS layout.

One option may be to inspect the template and/or stack resources looking for the presence of the pseudo serverless resource type. Or perhaps serverless stacks have some form of tag attached that we can use. When we can identify apps, we can make suitable queries to populate the sub nodes in the container.

One other option if we cannot auto-identify would be to give the user command gestures to add stacks to their resource tree for a region (and remove them). This approach would also require multi-select in the resource picker.

• Credentials list shows the select-able credentials in the following order:
  • Five most recent to least recently selected credentials
  • default (if it isn't in the MRU)
  • everything else sorted alphanumeric
• VS Code doesn't support separators in the picker list. See if we can decorate the MRU items with "recently used", much like the command palette shows to the right of other commands

If we want to attract outside contributors, we should make it as easy as possible for them to get started. Our current CONTRIBUTING.md has instructions about submitting issues, pull requests, etc., but doesn't contain "Getting Started" instructions.

At minimum, we should include:

• A list of all dependencies (i.e. node, npm) required to set up a dev environment.
• Instructions to build the toolkit.
• Instructions to run tests on the toolkit.
• Instructions to launch a VS Code instance with the toolkit enabled.

Having deployed a Lambda function that responds to events, the next logical step is for the user to configure the event source. This task is to design this interaction ready for implementation.

Some options that have been floated:

• a resource type sub-container view that either lists all possible event source types (S3 bucket etc) that can be added; user starts their event configuration from here with next steps to list resources of that type etc
• a view displaying 'favorite resources' (actual resource instances) that the user can control via add/remove command gestures (similar to regions); selecting a resource then invoking a command gesture gets the configuration process started
• a multi-step command gesture (similar to credentials) that lets the user select resource, then instance of type etc.
• what other approaches make sense?

We currently refer to this view as "the Explorer", which is vague and ambiguous. We should choose a more meaningful name, and use that name consistently throughout our tooling.

Some ideas:

• Resource Explorer
• AWS Resource Explorer
• AWS Explorer

Currently the explorer shows "...no functions for this region..." like so:

It probably makes more sense to either have this show as a disabled node so that it's more obvious it's a placeholder node.

If a user has lots of Lambda functions, how should we show them in the explorer? Show them all, or have a cut-off and a 'virtual' 'Show more....' entry that retrieves all of them?

Output from task is a design document for discussion, yielding one or more tasks for implementation.

Requires SSO hooks to be available

• define and document an extension preference that is a collection of SSO endpoints
• each endpoint should have a corresponding display name string
• selecting to sign in with SSO presents the list stored in preferences
  • if no entries are found in preferences, inform the user that no SSO endpoints are defined, and how they can add some
• selecting an item from the list triggers SSO flow through a browser
• when signed in, the status bar should show information about the connected account

The current provider populates only a Lambda functions sub-container. If we are to support serverless apps too we'll want them to be contained in their own container.

The container will enumerate the currently bound workspace regions, but we need to determine how to identify a serverless app stack vs a 'regular' CloudFormation stack. For this issue it's sufficient to add the sub container and the bound regions; each region can show a 'no deployed applications' placeholder.

The CLI has the ability to store a default region for a given profile in the secondary config file. When a credential profile is selected and no region settings have been persisted in the workspace, check the config file to see if we can source an initial region for the Explorer for the profile that is now in use.

Question to resolve: if the user has configured their workspace with one or more regions, and the config file also has a setting for a region that does not intersect should be (1) ignore, (2) adopt it automatically into the Explorer or (3) prompt the user to see if they want to add it to their settings?

Need to use css in the web view to make it a bit more attractive :-)