lambda-live-debugger 0.0.91 → 0.0.93

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -2,90 +2,106 @@
2
2
 
3
3
  ![Logo](logo.png)
4
4
 
5
- Lambda Live Debugger is an indispensable tool that allows you to debug AWS Lambda from your computer, although it is deployed on the cloud. It supports Lambdas written in JavaScript or TypeScript.
5
+ Lambda Live Debugger is an indispensable tool for debugging AWS Lambda functions from your computer, even though they are deployed in the cloud. It supports Lambdas written in JavaScript or TypeScript.
6
6
 
7
- This is essentially the same as offered by [SST](https://sst.dev/) and [Serverless Framework v4](https://www.serverless.com/blog/serverless-framework-v4-general-availability), except it supports an additional Obserability mode.
7
+ This tool offers similar functionality to [SST](https://sst.dev/) and [Serverless Framework v4](https://www.serverless.com/blog/serverless-framework-v4-general-availability), with the addition of an Observability mode.
8
8
 
9
9
  It supports the following frameworks:
10
10
 
11
- - AWS CDK v2,
12
- - Serverless Framework v3 (SLS),
13
- - AWS Serverless Application Model (SAM),
14
- - Terraform,
15
- - by implementing a simple function and option to support any framework or setup you might have,
16
- - ... (if you need any other framework, let me know?)
11
+ - AWS CDK v2
12
+ - Serverless Framework v3 (SLS)
13
+ - AWS Serverless Application Model (SAM)
14
+ - Terraform
15
+ - Any other framework or setup by implementing a simple function in TypeScript
16
+ - ... (Need support for another framework? Let me know!)
17
17
 
18
- ## Early alpha state
18
+ ## Early Alpha State
19
19
 
20
- **Currently, the project is in the early alpha state. Please let me know if everything works for you. A simple message would help a lot, so I know I am on the right track. I tested many scenarios, but there are numerous ways how people can configure projects and TypeScript configuration. The tool is flexible enough, so the settings can be tweaked to adjust your setup without implementing additional features. Any advice on how to improve the project is also very welcome.**
20
+ **This project is in the early alpha stage. Your feedback is incredibly valuable. Please let me know if it works for you or if you encounter any issues. I've tested many scenarios, but people can configure their projects and TypeScript settings in numerous ways. The tool is flexible and can be adjusted to fit your setup in most cases without needing additional features. If you need help, please let me know. Any suggestions for improvements are welcome.**
21
21
 
22
- You can contact me by:
22
+ Contact me via:
23
23
 
24
- - [Open GitHub issue](https://github.com/ServerlessLife/lambda-live-debugger/issues)
24
+ - [GitHub Issues](https://github.com/ServerlessLife/lambda-live-debugger/issues)
25
25
  - [LinkedIn](http://www.linkedin.com/in/marko-serverlesslife)
26
26
 
27
- ## The problem statement
27
+ ## The Problem Statement
28
28
 
29
- The serverless is amazing and resolves many issues that regular systems face. But writing code can be a struggle. You write code, deploy, run, fix, deploy again. That process is time-consuming and tiresome. You can also use one of the tools for running code locally or use unit/integration tests for that, but that has many other issues, and it does not mimic an actual environment close enough.
29
+ Serverless is amazing and solves many issues with traditional systems. However, writing code for Lambda functions can be challenging. The cycle of writing, deploying, running, fixing, and redeploying is time-consuming and tedious. While local testing tools and unit/integration tests exist, they often don't replicate the actual environment closely enough.
30
30
 
31
- ## How does it work
31
+ ## How It Works
32
32
 
33
- It connects to your deployed Lambda, sends the request to your computer, and sends the response back to Lambda. This way, you can debug on your machine, but the system behaves as if the code is running in the cloud with the same permissions.
33
+ Lambda Live Debugger connects to your deployed Lambda, routes requests to your computer, and sends responses back to the Lambda. This allows you to debug locally, but the system behaves as if the code is running in the cloud with the same permissions.
34
34
 
35
- Lambda Live Debugger attaches Lambda Extensions (via Layer) to the Lambda to intercept calls and send them to AWS IoT. AWS IoT is used to transfer messages to and from your machine. Lambda Live Debugger runs locally, connects to the AWS IoT, and executes the code locally. If Lambda is written in TypeScript, it is transpiled to JavaScript. Calls are executed via Node Worker Threads.
35
+ The tool attaches Lambda Extensions (via a Layer) to intercept and relay calls to AWS IoT, transferring messages between your Lambda and local machine. If the Lambda is written in TypeScript, it's transpiled to JavaScript. The code is executed via Node Worker Thread.
36
36
 
37
37
  ![Architecture](./architecture.drawio.png)
38
38
 
39
- Lambda Live Debugger makes the following changes to your AWS infrastructure:
39
+ ### Infrastructure Changes
40
40
 
41
- - Lambda excentions as a Layer
42
- - Attach Layer to each Lambda that you are debugging
43
- - Add policy to Lambda Role to use AWS IoT
41
+ Lambda Live Debugger makes the following changes to your AWS infrastructure:
44
42
 
45
- In case you do not want to add Layer to all functions, you can limit to the ones you need via configuration parameters.
43
+ - Adds Lambda Layer
44
+ - Attaches the Layer to each Lambda you're debugging
45
+ - Adds a policy to the Lambda Role for AWS IoT access
46
46
 
47
- While compiling, it creates many temporary files in the folder `.lldebugger`; you can freely delete the folder once you are done debugging or add `.lldebugger` to `.gitignore`. The wizard adds that for you if you want.
47
+ In case you do not want to debug all functions and add Layer to them, you can limit to the ones you need via the `function` parameter.
48
48
 
49
- ## Your developing process with Lambda Live Debugger
49
+ The tool generates temporary files in the `.lldebugger` folder, which can be deleted after debugging. The wizard can add `.lldebugger` to `.gitignore` for you.
50
50
 
51
- Since you will be deploying code into an actual AWS account while developing, you must use that environment only for yourself or create a temporary environment for you or for a feature you are working on.
51
+ ## Development Process
52
52
 
53
- Unfortunately, having a separate AWS environment is not always possible because of organizational issues (it is 2024, and companies still do not understand how to work with serverless) or technical issues (it is hard to duplicate databases or other parts of the system). For that purpose, there is an Observability Mode.
53
+ Since you deploy code to a real AWS account, it's best to have a dedicated environment only for yourself. It could be your personal environment or an environment created for a feature. That is [common practice when developing serverless systems](https://theburningmonk.com/2019/09/why-you-should-use-temporary-stacks-when-you-do-serverless/). If that's not feasible due to organizational or technical reasons, use Observability Mode.
54
54
 
55
55
  ## Observability Mode
56
56
 
57
- In Observability Mode, Lambda Live Debugger via Lambda Extension just intercepts the request received by Lambda and forwards it to the local environment, but it does not wait for the response. After that, Lambda continues regular execution and ignores the response from the local environment. The system is not impacted, and regular users and other developers can continue to use it. You can run Observability Mode on the development or testing environment. If you are an adventurer, you can even run it in production. In observability mode, you do not get all Lambda requests. You only get one every 3 seconds. You can configure that interval via `interval` setting. This way, the system will not be overloaded if there are a lot of requests coming in.
57
+ In Observability Mode, Lambda Live Debugger intercepts requests and sends them to your computer without waiting for a response. The Lambda continues as usual. The response from your machine is ignored. This mode can be used in the development, testing, or even, if you are an adventurous, production environment. It samples requests every 3 seconds by default (configurable with an `interval` setting) to avoid overloading the system.
58
58
 
59
- ## How to start
59
+ ## Getting Started
60
60
 
61
61
  ### Installation
62
62
 
63
- Install locally:
64
- `npm install lambda-live-debugger`
65
- or globally
66
- `npm install lambda-live-debugger -g` (Linux, Mac: `sudo npm install lambda-live-debugger -g`)
63
+ Install globally:
64
+
65
+ ```
66
+ npm install lambda-live-debugger -g
67
+ ```
68
+
69
+ _(On Linux and Mac: `sudo npm install lambda-live-debugger -g`)_
70
+
71
+ or locally
72
+
73
+ ```
74
+ npm install lambda-live-debugger -g
75
+ ```
76
+
77
+ _(If installed locally, you must prefix all commands with `npx`, if they are not part of `scripts` in `package.json`.)_
78
+
79
+ ## Running the Tool
67
80
 
68
- ### How to run
81
+ With default profile, region, and other default settings:
69
82
 
70
- If you use the default profile, default region, and other default settings then just run:
83
+ ```
84
+ lld
85
+ ```
71
86
 
72
- `lld` or `npx lld` (if installed locally)
87
+ You probably need to tweak some settings. You can do it via CLI parameters or, better, run the wizard:
73
88
 
74
- But you probably need to tweak some settings. You can do it via CLI parameters or, better run a wizard. The configuration is saved to `lldebugger.config.ts`
89
+ ```
90
+ lld -w
91
+ ```
75
92
 
76
- `npx lld -w` or `lld -w` (if installed globally)
93
+ The configuration is saved to `lldebugger.config.ts`
77
94
 
78
- ### CLI parameters
95
+ ### CLI Parameters
79
96
 
80
97
  ```
81
98
  -V, --version output the version number
82
- -r, --remove [option] Remove Lambda Live Debugger infrastructure. Options: 'keep-layer' (default),
83
- 'remove-all'
84
- -w, --wizard Program interactively asks for each parameter
99
+ -r, --remove [option] Remove Lambda Live Debugger infrastructure. Options: 'keep-layer' (default), 'remove-all'. The latest also removes the Lambda Layer
100
+ -w, --wizard Program interactively asks for each parameter and saves it to lldebugger.config.ts
85
101
  -v, --verbose Verbose logs
86
102
  -c, --context <context> AWS CDK context (default: [])
87
103
  -s, --stage <stage> Serverless Framework stage
88
- -f, --function <function name> Filter by function name
104
+ -f, --function <function name> Filter by function name. You can use * as a wildcard
89
105
  -m, --subfolder <subfolder> Monorepo subfolder
90
106
  -o, --observable Observable mode
91
107
  -i --interval <interval> Observable mode interval (default: "3000")
@@ -102,34 +118,31 @@ But you probably need to tweak some settings. You can do it via CLI parameters o
102
118
 
103
119
  You might want to configure your development tool for debugging. The wizard automatically configures for VsCode in `.vscode/launch.json`. Here is an example:
104
120
 
105
- ```
121
+ ```json
106
122
  {
107
- "version": "0.2.0",
108
- "configurations": [
109
-
110
- {
111
- "name": "Lambda Live Debugger",
112
- "type": "node",
113
- "request": "launch",
114
- "runtimeExecutable": "${workspaceFolder}/node_modules/.bin/lld",
115
- "runtimeArgs": [],
116
- "console": "integratedTerminal",
117
- "skipFiles": [
118
- "<node_internals>/**"
119
- ],
120
- "env": {}
121
- },
122
- ]
123
+ "version": "0.2.0",
124
+ "configurations": [
125
+ {
126
+ "name": "Lambda Live Debugger",
127
+ "type": "node",
128
+ "request": "launch",
129
+ "runtimeExecutable": "${workspaceFolder}/node_modules/.bin/lld",
130
+ "runtimeArgs": [],
131
+ "console": "integratedTerminal",
132
+ "skipFiles": ["<node_internals>/**"],
133
+ "env": {}
134
+ }
135
+ ]
123
136
  }
124
137
  ```
125
138
 
126
- If you are using another tool, please send me documentation so I can include it here. Especially the instruction for WebStorm is needed.
139
+ For other tools, please send documentation to include here. WebStorm instructions are especially needed.
127
140
 
128
- ### Monorepo
141
+ ## Monorepo Setup
129
142
 
130
- If your framework is one of the subfolders, set the `subfolder˙ setting.
143
+ Set the `subfolder` parameter if your framework is in a subfolder.
131
144
 
132
- ## Custom configuraiton
145
+ ## Custom Configuration
133
146
 
134
147
  getLambdas: async (foundLambdas) => {
135
148
  //you can customize the list of lambdas here or create your own
@@ -138,56 +151,64 @@ getLambdas: async (foundLambdas) => {
138
151
 
139
152
  ## Removing
140
153
 
141
- You can remove Lambda Live Debugger from your AWS account by running:
142
- `lld -r` (`npx lld -r` if installed locally)
154
+ To remove Lambda Live Debugger from your AWS account
155
+
156
+ ```
157
+ lld -r
158
+ ```
159
+
160
+ This detaches the Layer from your Lambdas and removes the IoT permission policy. It will not remove the Layer as others might use it.
143
161
 
144
- This will detach the Layer from your Lambda and remove the additional IoT permission policy.
162
+ To also remove the Layer:
163
+
164
+ ```
165
+ lld -r=all
166
+ ```
145
167
 
146
- It will not remove the Layer as others might use it. You can do everything, including Layer, with:
147
- `lld -r=all` (`npx lld -r=all` if installed locally)
168
+ ## Framework-Specific Notes
148
169
 
149
- ## AWS CDK v2
170
+ ### AWS CDK v2
150
171
 
151
- `context` is an additional setting for CDK. This is a common way to pass various variables to your code, most often the environment name.
172
+ Use the `context` parameter to pass context to your CDK code. This is a common way to pass variables to your code, most often the environment name.
152
173
 
153
- ## Serverless Framework v3 (SLS)
174
+ ### Serverless Framework v3 (SLS)
154
175
 
155
- `stage` is an additional setting for SLS to pass the stage/environment name to SLS.
176
+ Use the `stage` parameter to pass the stage/environment name.
156
177
 
157
- ## AWS Serverless Application Model (SAM)
178
+ ### AWS Serverless Application Model (SAM)
158
179
 
159
- `config-env` is an additional setting for SAM to pass the stage/environment name to SLS.
180
+ Use the `config-env` parameter to pass the stage/environment name.
160
181
 
161
- ## Terraform
182
+ ### Terraform
162
183
 
163
- Only the most basic setup for Terraform is supported. Check the test case [in](https://github.com/ServerlessLife/lambda-live-debugger/tree/main/test/terraform-basic).
184
+ Only the basic setup is supported. Check the [test case](https://github.com/ServerlessLife/lambda-live-debugger/tree/main/test/terraform-basic).
164
185
 
165
- I am not a Terraform developer, so I only know the basics. Please provide a project sample so I can build better support.
186
+ I am not a Terraform developer, so I only know the basics. Please provide a sample project so I can build better support.
166
187
 
167
188
  ## Know issues
168
189
 
169
- ## Missing features
190
+ ...
170
191
 
171
- Please check the open [issues](https://github.com/ServerlessLife/lambda-live-debugger/issues).
192
+ ## Missing Features
172
193
 
173
- The most important missing feature is MFA authentication and the most possible configuration for Terraform.
194
+ Check the [open issues](https://github.com/ServerlessLife/lambda-live-debugger/issues). The biggest missing feature right now is MFA authentication and more Terraform configurations.
174
195
 
175
- ## Reporting an issue
196
+ ## Reporting an Issue
176
197
 
177
- - Make sure the bug is not already reported. Add +1 comment so I know there are multiple users struggling with the same issue. If possible, add some additional info.
178
- - Make a descriptive title with the prefix "bug:", "help:", "feature:", "discussion:" to indicate if you find a bug, need help, propose a feature... Please also add the matching label and, if needed, set priority via label.
179
- - Turn on verbose logging and provide the whole log.
180
- - Carefully describe your setup, or even better, provide a sample project.
198
+ - Make sure the bug hasn't already been reported. Add a "+1" comment so I know there are multiple users struggling with the same issue. If possible, add some additional info.
199
+ - Use descriptive titles with prefixes like "bug:", "help:", "feature:", or "discussion:". Please also add the matching label and, if needed, set priority via a label.
200
+ - Enable verbose logging and provide the full log.
201
+ - Describe your setup in detail, or better yet, provide a sample project.
181
202
 
182
203
  ## Authors:
183
204
 
184
205
  - [Marko (ServerlessLife)](https://github.com/ServerlessLife)
185
- - ⭐ place for you for large code contribution
206
+ - ⭐ Your name here for big code contributions
186
207
 
187
208
  ## Contributors (alphabetical)
188
209
 
189
- - ⭐ place for you for smaller code/documentation contributions or a sample project as a part of a bug report
210
+ - ⭐ Your name here for smaller code/documentation contributions or sample projects as part of bug reports
190
211
 
191
212
  ## Declarment
192
213
 
193
- Use this tool at your responsibility...
214
+ Lambda Live Debugger is provided "as is", without warranty of any kind, express or implied. Use it at your own risk, and be mindful of potential impacts on performance, security, and costs when using it in your AWS environment.
Binary file
@@ -11,15 +11,15 @@ export async function getConfigFromCliArgs(supportedFrameworks = []) {
11
11
  const version = await getVersion();
12
12
  const program = new Command();
13
13
  program.name("lld").description("Lambda Live Debugger").version(version);
14
- program.option("-r, --remove [option]", "Remove Lambda Live Debugger infrastructure. Options: 'keep-layer' (default), 'remove-all'. The lates also remove the Lambda Layer"
14
+ program.option("-r, --remove [option]", "Remove Lambda Live Debugger infrastructure. Options: 'keep-layer' (default), 'remove-all'. The latest also removes the Lambda Layer"
15
15
  //validateRemoveOption,
16
16
  //"keep-layer"
17
17
  );
18
- program.option("-w, --wizard", "Program interactively asks for each parameter and save it to lldebugger.config.ts");
18
+ program.option("-w, --wizard", "Program interactively asks for each parameter and saves it to lldebugger.config.ts");
19
19
  program.option("-v, --verbose", "Verbose logs");
20
20
  program.option("-c, --context <context>", "AWS CDK context", (value, previous) => previous.concat(value), []);
21
21
  program.option("-s, --stage <stage>", "Serverless Framework stage");
22
- program.option("-f, --function <function name>", "Filter by function name. You can use * as wildcard");
22
+ program.option("-f, --function <function name>", "Filter by function name. You can use * as a wildcard");
23
23
  program.option("-m, --subfolder <subfolder>", "Monorepo subfolder");
24
24
  program.option("-o, --observable", "Observable mode");
25
25
  program.option("-i --interval <interval>", "Observable mode interval", defaultObservableInterval.toString());
Binary file
@@ -49587,6 +49587,26 @@ function splitMessageToChunks(input) {
49587
49587
 
49588
49588
  // ../ioTService.ts
49589
49589
  var import_client_iot = __toESM(require_dist_cjs55(), 1);
49590
+
49591
+ // ../logger.ts
49592
+ var verboseEnabled = false;
49593
+ function verbose(...args) {
49594
+ if (verboseEnabled) {
49595
+ console.info(...args);
49596
+ }
49597
+ }
49598
+ function setVerbose(enabled) {
49599
+ verboseEnabled = enabled;
49600
+ }
49601
+ var Logger = {
49602
+ log: console.log,
49603
+ error: console.error,
49604
+ warn: console.warn,
49605
+ verbose,
49606
+ setVerbose
49607
+ };
49608
+
49609
+ // ../ioTService.ts
49590
49610
  var device2;
49591
49611
  var chunks = /* @__PURE__ */ new Map();
49592
49612
  async function getIoTEndpoint({
@@ -49628,20 +49648,20 @@ async function connect(props) {
49628
49648
  });
49629
49649
  if (props?.topic) {
49630
49650
  device2.subscribe(props.topic, { qos: 1 });
49631
- console.debug("Subscribed to topic ", props.topic);
49651
+ Logger.verbose("[IoT] Subscribed to topic ", props.topic);
49632
49652
  }
49633
49653
  device2.on("connect", () => {
49634
- console.debug("IoT connected");
49654
+ Logger.verbose("[IoT] Connected");
49635
49655
  connectedPromiseResolve();
49636
49656
  });
49637
49657
  device2.on("error", (err) => {
49638
- console.debug("IoT error", err);
49658
+ Logger.error("[IoT] Error", err);
49639
49659
  });
49640
49660
  device2.on("close", () => {
49641
- console.debug("IoT closed");
49661
+ Logger.verbose("[IoT] Closed");
49642
49662
  });
49643
49663
  device2.on("reconnect", () => {
49644
- console.debug("IoT reconnecting...");
49664
+ Logger.verbose("[IoT] Reconnecting...");
49645
49665
  });
49646
49666
  if (props?.onMessage) {
49647
49667
  const messageReceived = (topic2, buffer) => {
@@ -49664,6 +49684,7 @@ async function connect(props) {
49664
49684
  };
49665
49685
  device2.on("message", messageReceived);
49666
49686
  }
49687
+ await connectedPromise;
49667
49688
  return {
49668
49689
  publish: async (payload, topic2) => {
49669
49690
  await connectedPromise;
@@ -49688,24 +49709,6 @@ var IoTService = {
49688
49709
  connect
49689
49710
  };
49690
49711
 
49691
- // ../logger.ts
49692
- var verboseEnabled = false;
49693
- function verbose(...args) {
49694
- if (verboseEnabled) {
49695
- console.info(...args);
49696
- }
49697
- }
49698
- function setVerbose(enabled) {
49699
- verboseEnabled = enabled;
49700
- }
49701
- var Logger = {
49702
- log: console.log,
49703
- error: console.error,
49704
- warn: console.warn,
49705
- verbose,
49706
- setVerbose
49707
- };
49708
-
49709
49712
  // interceptor.ts
49710
49713
  var workerId = import_crypto5.default.randomBytes(16).toString("hex");
49711
49714
  var topic = `${process.env.LLD_DEBUGGER_ID}/events/${workerId}`;