Merge pull request #1580 from aws/autoMerge/feature/featureDev-codegen

Merge staging into feature/featureDev-codegen

Author: jpinkney-aws

.changes/2.11.0.json

@@ -0,0 +1,18 @@
+{
+	"date": "2024-02-22",
+	"version": "2.11.0",
+	"entries": [
+		{
+			"type": "Feature",
+			"description": "Amazon Q: /dev command now supports the InvalidState event during the GenerateApproach step. The reason for the Approach to reach an Invalid State is printed in /dev's chat response."
+		},
+		{
+			"type": "Feature",
+			"description": "CloudFormation and SAM templates now have a CodeLens link to Application Composer"
+		},
+		{
+			"type": "Feature",
+			"description": "Amazon Q CodeTransformation: show user build logs for Maven install and copy-deps commands"
+		}
+	]
+}

.changes/next-release/Bug Fix-3c1e992b-b24d-418d-a91b-a0cf4d2e7b66.json

@@ -0,0 +1,4 @@
+{
+	"type": "Bug Fix",
+	"description": "Amazon Q: Static analysis of document symbols used as context in Amazon Q requests must filter tree-sitter \"extra\" CST nodes (comments) in order to avoid crashes which freeze the chat panel"
+}

.changes/next-release/Feature-1340e969-a0c6-4aa5-92e1-ecaedd52a20b.json

@@ -0,0 +1,4 @@
+{
+	"type": "Feature",
+	"description": "Enable node 20 for SAM create and local Lambda debugging"
+}

.changes/next-release/Feature-214097b6-7e2e-4a96-a932-3f8966939f7c.json

@@ -0,0 +1,4 @@
+{
+	"type": "Feature",
+	"description": "CodeWhisperer: Add startUrl to security scan telemetry"
+}

.changes/next-release/Feature-abf2914f-ebe4-4612-b06a-d0c069b3e49c.json

@@ -52,5 +52,5 @@ packages/toolkit/resources/css/icons.css
 .local.env
 *.config.local.json
 
-# Created by `npm run browserRun` when testing extension in the browser
+# Created by `npm run webRun` when testing extension in web mode
 .vscode-test-web

.gitignore

@@ -1,3 +1,9 @@
+## 2.11.0 2024-02-22
+
+- **Feature** Amazon Q: /dev command now supports the InvalidState event during the GenerateApproach step. The reason for the Approach to reach an Invalid State is printed in /dev's chat response.
+- **Feature** CloudFormation and SAM templates now have a CodeLens link to Application Composer
+- **Feature** Amazon Q CodeTransformation: show user build logs for Maven install and copy-deps commands
+
 ## 2.10.0 2024-02-16
 
 - **Bug Fix** CDK Explorer: Refresh button is now visible.

CHANGELOG.md

@@ -148,11 +148,11 @@ You can also use these NPM tasks (see `npm run` for the full list):
 
 ---
 
-### Browser
+### Web Mode
 
-The AWS Toolkit VSCode extension has a support (with limited functionality) for running in the browser, eg [vscode.dev](https://vscode.dev).
+The AWS Toolkit VSCode extension has a support (with limited functionality) for running in a web browser, eg [vscode.dev](https://vscode.dev).
 
-See [browser.md](./docs/browser.md) for working with the browser implementation of the extension.
+See [web.md](./docs/web.md) for working with the web mode implementation of the extension.
 
 ---
 
@@ -214,12 +214,6 @@ To run tests against a specific folder in VSCode, do any one of:
         $Env:TEST_DIR = "src/test/foo"; npm run test
         ```
 
-### Browser Support
-
-Running the extension in the browser (eg: [vscode.dev](https://vscode.dev/)).
-
-[See documentation here](./packages/toolkit/src/browser/README.md).
-
 ### Coverage report
 
 You can find the coverage report at `./coverage/index.html` after running the tests. Tests ran from the workspace launch config won't generate a coverage report automatically because it can break file watching. A few manual steps are needed instead:

CONTRIBUTING.md

@@ -6,7 +6,7 @@ An overview of the architecture for various components within the Toolkit.
 
 This project is currently set up as a typescript monorepo with a single subproject.
 We are currently working on splitting the Toolkit into various subprojects to help with
-sharing code between modules, browser extension development, etc. For now, there is just
+sharing code between modules, Web mode development, etc. For now, there is just
 one monolithic subproject with all the extension functionality: [`packages/toolkit/`](./packages/toolkit/).
 
 Unless otherwise stated, the documentation throughout this project is referring to the code and
@@ -337,7 +337,14 @@ Abstractly, a 'wizard' is a collection of discrete, linear steps (subroutines),
 
 ### Creating a Wizard (Quick Picks)
 
-A new wizard can be created by extending off the base `Wizard` class, using the template type to specify the shape of the wizard state. All wizards have an internal 'form' property that is used to assign steps. We can assign UI elements (namely, quick picks) using the `bindPrompter` method on form elements. This method accepts a callback that should return a `Prompter` given the current state. For this example, we will use `createQuickPick` and `createInputBox` for our prompters:
+Create a new wizard by extending the base `Wizard` class, using the template type to specify the
+shape of the wizard state. All wizards have an internal `form` property that is used to assign
+steps. You can assign UI elements (namely, quickpicks) using the `bindPrompter` method on form
+elements. This method accepts a callback that should return a `Prompter` given the current state.
+For this example, we will use `createQuickPick` and `createInputBox` for our prompters:
+
+If you need to call async functions to construct your `Wizard` subclass, define your init logic in
+the `init()` method instead of the constructor.
 
 ```ts
 interface ExampleState {
@@ -382,7 +389,7 @@ Note that all wizards can potentially return `undefined` if the workflow was can
 Use `createWizardTester` on an instance of a wizard. Tests can then be constructed by asserting both the user-defined and internal state. Using the above `ExampleWizard`:
 
 ```ts
-const tester = createWizardTester(new ExampleWizard())
+const tester = await createWizardTester(new ExampleWizard())
 tester.foo.assertShowFirst() // Fails if `foo` is not shown (or not shown first)
 tester.bar.assertDoesNotShow() // True since `foo` is not assigned an explicit value
 tester.foo.applyInput('Hello, world!') // Manipulate 'user' state

docs/ARCHITECTURE.md

@@ -1,25 +1,25 @@
-# Browser
+# Web Mode
 
-This extension can run in the web browser (eg: [vscode.dev](https://vscode.dev)), but with limited functionality compared to
+This extension can run in a web browser (eg: [vscode.dev](https://vscode.dev)), but with limited functionality compared to
 the desktop version.
 
-## Running the Browser implementation
+## Running the Web mode implementation
 
-You can run the browser implementation of the extension in the following ways.
+You can run the Web mode implementation of the extension in the following ways.
 
 ## Pre-requisites
 
 [See the CONTRIBUTING document.](../CONTRIBUTING.md#setup)
 
 ### General Notes
 
--   To see logs, using the Command Palette search: `Toggle Developer Tools`. Then go to the `Console` tab. In browser mode VS Code seems to duplicate log messages, idk how to fix this.
--   The difference between browser mode and Node.js/desktop is that browser mode is in an actual browser environment so certain things like Node.js modules will **not** be available.
+-   To see logs, using the Command Palette search: `Toggle Developer Tools`. Then go to the `Console` tab. In web mode VS Code seems to duplicate log messages, idk how to fix this.
+-   The difference between web mode and Node.js/desktop is that in web mode everything runs in browser environment so certain things like Node.js modules will **not** be available.
 
 ## Running in an actual Browser
 
 The following steps will result in a Chrome window running with VS Code
-and the Browser version of the AWS Toolkit extension installed:
+and the web version of the AWS Toolkit extension installed:
 
 1. (Recommended) To have the Chrome window save your VS Code state after closing it, you need to modify the node module which executes the playwright method that opens it. In `node_modules/@vscode/test-web/out/index.js#openBrowser()` make the following change:
 
@@ -51,26 +51,30 @@ and the Browser version of the AWS Toolkit extension installed:
 
 #### (OPTIONAL) Enabling CORS
 
-By default, we disable CORS in browser mode since certain endpoints
+By default, we disable CORS in web mode since certain endpoints
 such as telemetry or auth do not support CORS (at the moment of writing) for the VSCode origin.
 
 In the case you want to enable CORS in the browser to test CORS compatibility
 do the following:
 
--   In `package.json` find the `browserRun` script
+-   In `package.json` find the `webRun` script
 -   Temporarily remove `--browserOption=--disable-web-security`
 
 Now when you run the extension in the browser it will do CORS checks.
 
-## Testing in VSCode Browser Mode
+## Testing in VSCode Web Mode
 
 The following steps will result in a VSCode Extension window running
 with the AWS Toolkit extension installed. While it looks the same as a typical
 VS Code window, in the background it is running in a Browser context.
 
--   In the `Run & Debug` menu run: `Extension Tests (browser)`
+-   In the `Run & Debug` menu run: `Extension Tests (web)`
 
-> NOTE: Tests do not spin up an actual Browser window, but if we find a good reason to switch it will require some additional work. The current way does not require dowloading a separate browser like Chromium.
+> NOTE: Tests do not spin up an actual browser window, but if we find a good reason to switch it will require some additional work. The current way does not require dowloading a separate browser like Chromium.
+
+## Adding Web mode specific npm modules
+
+If you need to manage npm modules required for Web mode, such as a [browserfied module](https://www.npmjs.com/package/os-browserify), see [the documentation here](../packages/toolkit/src/web/README.md).
 
 ## Finding incompatible transitive dependencies
 
@@ -97,13 +101,13 @@ to help us visualize the imports and determine which module is importing a certa
 
 ### Summary
 
--   **When in Browser mode**, state is not shared between the actual extension code and the unit test code. I.e you cannot modify a global variable in the extension code and see that change in the unit tests
+-   **When in Web mode**, state is not shared between the actual extension code and the unit test code. I.e you cannot modify a global variable in the extension code and see that change in the unit tests
 -   State will need to be stored somewhere in `globalThis` to be accessible by tests. Any state not in `globalThis` will not be the same as the actual extension, they are separate.
 
-With the introduction of Browser support, it was discovered that the context between the extension code and test code is not shared.
+With the introduction of web mode support, it was discovered that the context between the extension code and test code is not shared.
 Though it is shared in the Node version of the extension.
 
-Example that does NOT work in the Browser:
+Example that does NOT work in Web mode:
 
 ```typescript
 export let myGlobal = 'A'
@@ -115,17 +119,17 @@ function activate() {
 ```
 
 ```typescript
-// Browser unit test
+// Web unit test
 import { myGlobal } from '../src/extension.ts'
 
 describe('test', function () {
     it('test', function () {
-        assert.strictEqual(myGlobal, 'B') // this fails in Browser (but not Node.js). The value here is actually 'A'.
+        assert.strictEqual(myGlobal, 'B') // this fails in Web (but not Node.js). The value here is actually 'A'.
     })
 })
 ```
 
-Example that DOES work in the Browser:
+Example that DOES work in Web mode:
 
 ```typescript
 ;(globalThis as any).myGlobal = 'A'
@@ -136,17 +140,17 @@ function activate() {
 ```
 
 ```typescript
-// Browser unit test
+// Web unit test
 describe('test', function () {
     it('test', function () {
-        assert.strictEqual((globalThis as any).myGlobal, 'B') // this succeeds in Browser and Node.js
+        assert.strictEqual((globalThis as any).myGlobal, 'B') // this succeeds in Web and Node.js
     })
 })
 ```
 
 ### Web Worker
 
-The assumption for the behavior is due to how Web Workers work. We (VS Code) use them to run our extension and unit test code when in the Browser. The scripts share global values differently compared to a different environment such as Node.js.
+The assumption for the behavior is due to how Web Workers work. We (VS Code) use them to run our extension and unit test code when in the browser. The scripts share global values differently compared to a different environment such as Node.js.
 
 -   [`WorkerGlobalScope`](https://developer.mozilla.org/en-US/docs/Web/API/WorkerGlobalScope)
     -   The context of the executing code is contained within itself and is not accessible to other scripts (eg: extension code context is not accessible by unit tests)