From 7d6068103e82fa7533276ddee84f9b53efc29346 Mon Sep 17 00:00:00 2001 From: Rico Huijbers Date: Mon, 1 Jun 2020 10:09:52 +0200 Subject: [PATCH] chore: add a base VSCode config (#8184) VSCode configs for our repo are tricky enough that people would benefit from having them checked into the repo. Some people are strongly opposed to having them checked in at the default location though, for what I assume are the following reasons: - There's no good way to have user-specific, workspace-specific preferences, so one set of `.vscode` files would apply to everyone. - If you already had workspace-specific VSCode preferences, the new files would collide. - Not everyone uses VSCode, so if we start adding `.vscode` files, we should also start adding `.idea` files and others, and where will it end, and who's going to keep them consistent? As a compromise, adding a script which will copy a base VSCode config into place. You can choose the run the script if you want it, and you can choose not to run it if you don't. Everybody happy, right? If necessary, we'll be able to extend this in the future with custom per-user configs, but for now let's start with something simple. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license* --- .gitignore | 4 +++- .vscode/launch.json | 23 +++++++++++++++++++++++ CONTRIBUTING.md | 21 ++++++++++++++++++++- 3 files changed, 46 insertions(+), 2 deletions(-) create mode 100644 .vscode/launch.json diff --git a/.gitignore b/.gitignore index f8f8e687c6791..2cb016405e016 100644 --- a/.gitignore +++ b/.gitignore @@ -1,5 +1,7 @@ # VSCode extension -.vscode/ + +# Store launch config in repo but not settings +.vscode/settings.json /.favorites.json # TypeScript incremental build states diff --git a/.vscode/launch.json b/.vscode/launch.json new file mode 100644 index 0000000000000..66f6db80dcd14 --- /dev/null +++ b/.vscode/launch.json @@ -0,0 +1,23 @@ +{ + // Use IntelliSense to learn about possible attributes. + // Hover to view descriptions of existing attributes. + // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387 + "version": "0.2.0", + "configurations": [ + { + // Has convenient settings for attaching to a NodeJS process for debugging purposes + // that are NOT the default and otherwise every developers has to configure for + // themselves again and again. + "type": "node", + "request": "attach", + "name": "Attach to NodeJS", + // If we don't do this, every step-into into an async function call will go into + // NodeJS internals which are hard to step out of. + "skipFiles": [ + "/**" + ], + // Saves some button-pressing latency on attaching + "stopOnEntry": false + } + ] +} \ No newline at end of file diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 468cdf8b09e1d..810267a9ab428 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -43,6 +43,7 @@ and let us know if it's not up-to-date (even better, submit a PR with your corr - [Troubleshooting](#troubleshooting) - [Debugging](#debugging) - [Connecting the VS Code Debugger](#connecting-the-vs-code-debugger) + - [Run a CDK unit test in the debugger](#run-a-cdk-unit-test-in-the-debugger) - [Related Repositories](#related-repositories) ## Getting Started @@ -327,7 +328,7 @@ All packages in the repo use a standard base configuration found at [eslintrc.js This can be customized for any package by modifying the `.eslintrc` file found at its root. If you're using the VS Code and would like to see eslint violations on it, install the [eslint -extension](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint). +extension](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint). #### pkglint @@ -910,6 +911,24 @@ To debug your CDK application along with the CDK repository, 6. The debug view, should now have a launch configuration called 'Debug hello-cdk' and launching that will start the debugger. 7. Any time you modify the CDK app or any of the CDK modules, they need to be re-built and depending on the change the `link-all.sh` script from step#2, may need to be re-run. Only then, would VS code recognize the change and potentially the breakpoint. +### Run a CDK unit test in the debugger + +If you want to run the VSCode debugger on unit tests of the CDK project +itself, do the following: + +1. Set a breakpoint inside your unit test. +2. In your terminal, depending on the type of test, run either: + +``` +# (For tests names test.xxx.ts) +$ node --inspect-brk /path/to/aws-cdk/node_modules/.bin/nodeunit -t 'TESTNAME' + +# (For tests names xxxx.test.ts) +$ node --inspect-brk /path/to/aws-cdk/node_modules/.bin/jest -i -t 'TESTNAME' +``` + +3. On the `Run` pane of VSCode, select the run configuration **Attach to NodeJS** and click the button. + ## Related Repositories * [Samples](https://github.com/aws-samples/aws-cdk-examples): includes sample code in multiple languages