Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

VSCode debugging #364

Closed
franciscocpg opened this issue Apr 5, 2018 · 9 comments · Fixed by #365
Closed

VSCode debugging #364

franciscocpg opened this issue Apr 5, 2018 · 9 comments · Fixed by #365
Labels

Comments

@franciscocpg
Copy link
Member

Hi @HyperBrain
First of all, sorry for not using the issue template but this is a question (not a bug or feature propose).

Personally I don't use debug (just a personal preference, but I don't have nothing against it) but a lot of my coworkers are starting to request this feature in vscode with serverless-webpack.

So far I have found these references trying to start a debug session:

  1. https://hackernoon.com/running-and-debugging-aws-lambda-functions-locally-with-the-serverless-framework-and-vs-code-a254e2011010
  2. https://github.com/kube/vscode-ts-webpack-node-debug-example
  3. Add interactive debugging support #42

The 1. approach does not work out of the box for serverless-webpack so I've tried to mix it with the 2. approach without success.
Reading #42 it looks like you have success debugging.

If you can share in this issue how are you achieving that I could open a PR adding this topic to README (debugging in VSCODE) and updating some of our examples (let's say examples/babel-webpack-4) to show how to do that so others could have that benefit too.

@HyperBrain
Copy link
Member

HyperBrain commented Apr 6, 2018

Hi @franciscocpg , thanks for bringing this up.

yes, we indeed have debugging working here. It is setup via a task in .vscode/launch.json like this:

{
    // 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": [
        {
            "type": "node",
            "request": "launch",
            "name": "Launch Dev Offline",
            "program": "${workspaceRoot}/node_modules/serverless/bin/serverless",
            "args": [ "offline", "--noTimeout", "--dontPrintOutput", "--stage=dev" ],
            "sourceMaps": true,
            "runtimeArgs": [
              "--lazy"
            ],
            "outFiles": [
              "${workspaceFolder}/.webpack/**/*.js"
            ],
            "protocol": "inspector",
            "runtimeExecutable": "node",
            "env": {
              // Here we set some environment vars that should be set locally.
              // They can and will overwrite the ones coming from your serverless.yml
            },
            "windows": {
              "program": "${workspaceRoot}\\node_modules\\serverless\\bin\\serverless",
            }
        }
    ]
}

This works perfectly on Windows, MacOS and Linux. You even could add a launch task for each stage you debug.
Sometimes (not very often) the breakpoint evaluation does not work until a watched recompile (change something in the code) is triggered or it takes some time to switch breakpoints. I believe this is because of a bug in VSCode or Node. Using Node 9.x locally improved this situation for me.

The --lazy node switch is important, because it enables lazy breakpoint evaluation which is vital for webpack compiled code. The real code locations will only be known after the code is compiled.

As we have serverless installed with each project, our launch template of course refers to the serverless binary located in node_modules. But that should work the same with a globally installed serverless.

Additionally, I wrote the serverless-vscode extension for VSCode because I was annoyed by using a command line every time to do anything else than debugging (i.e. deploy a single function for debugging, inspecting the logs, etc...)
I would be happy if your coworkers could give it a try and maybe add some feature requests or PRs to the extension's GitHub repo 😄

@franciscocpg
Copy link
Member Author

Hi @HyperBrain
Thanks for your response.

I'm going to give a try using this .vscode/launch.json you've provided with https://github.com/serverless-heaven/serverless-webpack/tree/master/examples/babel-webpack-4. What do you think?

Also could you please provide a sample of the webpack.config.js you are using?
Because I think the line below has to be changed, right?

devtool: 'nosources-source-map',

@HyperBrain
Copy link
Member

HyperBrain commented Apr 6, 2018

The webpack config from the example should work. We also use nosources-source-map because it is sufficient to have the line number associations in the source maps and not the whole source.
This makes the sourcemaps quite small but functional.

So, the sample should work as given. Of course you have to add serverless-offline because the launch.json executes serverless offline .... However you could even add a second or third launch configuration that uses serverless invoke local instead. We use offline because it's more convenient for us.

@franciscocpg
Copy link
Member Author

It worked fine using serverless-offline (thank you 😃 🏅 ) but I was unable to make it work with invoke local by replacing "args": [ "offline", "--noTimeout", "--dontPrintOutput", "--stage=dev" ] with "args": [ "invoke", "local", "-f", "first" ].

After reading this article again I've changed to "args": [ "invoke", "local", "-f", "first", "--data", "{}" ] and "voilá".

I don't know why it works only when passing "--data", "{}", but it's working.

ASAP I'm going to open a PR adding those 2 configurations (with serverless-offine and invoke local) to babel-webpack-4. Also I'm going to create a section at README about vscode debug.

Are you ok with adding serverless-offline plugin to babel-webpack-4 example or do you prefer that I create another example for doing that?

@HyperBrain
Copy link
Member

HyperBrain commented Apr 6, 2018

Yes, add it to the example. I think it is already kind of standard to use serverless-offline.

BTW: The data option is quite strange, but good to hear that it works that way. I'm sure that is a bug in serverless. Any omitted data options should default the event data for invoke local to an empty object and not undefined.

@franciscocpg franciscocpg mentioned this issue Apr 6, 2018
7 tasks
@dhmacs
Copy link

dhmacs commented Jul 19, 2018

@HyperBrain the debugging config for vscode does not start dynamodb local, do you know why?

@HyperBrain
Copy link
Member

@Macs91 As far as I remember, you have to use serverless offline start as command together with dynamodb local. Can you try to add "start" to the offline command line in your launch.json?

@dhmacs
Copy link

dhmacs commented Jul 20, 2018

@HyperBrain I've already done so, but as soon as I add start it doesn't start neither the lambdas nor dynamodb.. Here's my launch.json

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "node",
      "request": "launch",
      "name": "Launch Serverless Offline",
      "program": "${workspaceRoot}/node_modules/serverless/bin/serverless",
      "args": ["offline", "start", "--noTimeout", "--dontPrintOutput"],
      "sourceMaps": true,
      "runtimeArgs": ["--lazy"],
      "outFiles": ["${workspaceFolder}/.webpack/**/*.js"],
      "protocol": "inspector",
      "runtimeExecutable": "node",
      "env": {
      },
      "windows": {
        "program": "${workspaceRoot}\\node_modules\\serverless\\bin\\serverless"
      }
    }
  ]
}

Without start everything works except for dynamodb

@quickdraw6906
Copy link

The --lazy node switch is important, because it enables lazy breakpoint evaluation which is vital for webpack compiled code. The real code locations will only be known after the code is compiled.

This doesn't work for me. Exceptions will get caught in VS Code, but execution stops and opens the webpack source (root/.build/.webpack/service/src) instead of root/src.

Note: I'm using serverless-bundle. Does that change anything?

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants