Debuggers support

[dherault]

Debuggers support

[mikestaub]

Not sure if everyone knows yet but as of node v6.3.x you can debug in chrome with the --inspect flag. No need for node-inspector anymore.

I ported this plugin to be compatible with v1.0.0-beta.1, feel free to check it out here: https://github.com/mikestaub/serverless-offline/commits/master

I am running this command with great success while developing locally:

export SLS_DEBUG=true; node --inspect --debug-brk $(which sls) offline

[jesucarr]

Yes, they are totally different things.

To the console log you can output anything you think might be useful to see in console.

What I mean with debugger support is that the node process is launched in debug mode.

For example, imagine that I have a file called server.js that starts a web server in port 3000. I can execute it normally with the node command:

$ node server.js
Server listening on port 3000

Now I can execute it in debug mode like this:

$ node --debug server.js
Debugger listening on port 5858
Server listening on port 3000

As you see now the debugger is listening on port 5858 (default port). I could launch a debugging tool on port 5858 and debug the code as it runs (place breakpoints, etc.). An example of such tool is node-inspector. I could just run node-debug (will debug at default port 5858) and debug from Chrome as you can with websites. There are also code editors that can launch their debugging tools in such debug port, like VS Code.

Hope it makes sense.

[WooDzu]

I keep serverless local which allows me to debug it like so:

node --debug node_modules/.bin/serverless offline start

but you might also be able to do the same for a global installation:

node --debug `which serverless` offline start

[leobarcellos]

On VSCode I can start debug process with this config:

{
      "name": "Serverless Debug",
      "type": "node",
      "request": "launch",
      "protocol": "inspector",
      "runtimeArgs": ["--inspect"],
      "cwd": "${workspaceFolder}",
      "program": "${workspaceFolder}/node_modules/.bin/sls",
      "args": ["offline"],
      "env": {
        "SLS_DEBUG": "*",
        "PYTHONPATH": "${workspaceFolder}/",
        "NODE_ENV": "development",
      },
      "console": "integratedTerminal"
    }

However it's useless because the breakpoints does not work (they are gray, and not red), with this message on hover:
Breakpoint ignored because generated code not found (source map problem?).

Well, I have no idea what to do, already tried setting up sourceMap: true, but with no success.

[Bilal-S]

Thanks @mikestaub and @dherault
I added a hook for 'start' for myself so you can issue backward compatible CLI call like
serverless offline start

However, I am running into a different error for the API calls. I will have to dig into that later:

HTTP response:
{"statusCode":500,"error":"Internal Server Error","message":"An internal server error occurred"}

Stack Trace start:
Debug: internal, implementation, error
    TypeError: Uncaught error: Cannot read property 'application/json' of undefined
  at server.route.handler.createLambdaContext (~/code/GitHub/proj4/node_modules/serverless-offline/src/index.js:347:53)

I would like to suggest that we create a 1.0 Branch of this plugin so we can consolidate work into a single project, update docs etc. David could you create a branch for us please?

[quantuminformation]

Anyone managed to this to work with webstorm, by allowing to debug lambda functions?

My use-case is to debug this locally:

https://github.com/laardee/serverless-authentication-gh-pages/blob/gh-pages/app.js#L3

[rsshilli]

@quantuminformation I got this to work in Webstorm. I'm starting Serverless offline like so:

node --debug node_modules/serverless/bin/serverless offline --stage <my-stage>

Then in Webstorm I go to Run -> Edit Configurations, add a new configuration and choose "Node.js Remote Debug". I left all of the default options and clicked OK. Then I click OK on the toolbar and voila, I'm debugging

What I really don't understand is how my co-worker was able to connect his VS Code debugger without adding that --debug flag above. Weird.

[Juanelorganelo]

@rsshilli

What I really don't understand is how my co-worker was able to connect his VS Code debugger
without adding that --debug flag above. Weird.

Not sure if this is what you meant, I'm using it like this in VS Code
it probably adds a --debug or --inspect flag automagically

{
  "type": "node",
  "request": "launch",
  "name": "Start API",
  "cwd": "${workspaceFolder}",
  "program": "/usr/local/bin/serverless",
  "args": [
    "offline",
    "start"
  ]
}

[awkward-minion]

sourceMap

@leobarcellos did you get any luck with these breakpoint configurations?

[dherault]

Yep, good idea. I can't PR since I've never used such tools. Is there a way to have both behaviors? (the console.log and the debugger output?)

[Bilal-S]

I think this is a fantastic idea.
If this is still an open issue I wouldn't mind taking a look into how to make that happen.
Let me know.

[vanerleo]

just a note that VS code now supports attaching to an existing node session, so you can debug it with vs code

[Bilal-S]

I think the idea is to go beyond setting node into debug state, also firing off a profiler, interactive environment with code changing, stack tracing and profiling ability. In other words ready to go to work. I like the idea of this with MS VS code, but an independent mechanism would be cool as well. I was thinking a link to node-inspector via chrome. Having a command as simple as:
sls-debug offline start
to trigger all. I will propose something in a pull request this weekend if time allows. I think this would be a small change with big benefits for developers.

[Bilal-S]

I was able to do this and I think this is the way to go to develop in serverless.
However, there is a few things that I need guidance on.
I can only build the hooks into the overall serverless framework, so I submitted a change there a few days ago; I have not received feedback from the serverless team on it whether it will be included in future versions.
I can just publish the changes for people to use on their own if there is interest?

The serverless framework is now in version 1, I looked at this plug-in on version 0.5.6 since the instructions with s-project.json etc refer to the earlier builds. The plug-in architecture for serverless seems to have changed and I will need to read through some docs to see how all transitions and maybe update the docs here as well. Did anyone try the offline plugin with serverless 1.0? How is the setup different?

[Bilal-S]

Mike,
Thanks for the 1.0 beta version info.
You make a good point and I can see how your approach can work. Similarly, VS Code has a mechanism to do this as mentioned earlier. There are a few things to consider though.

• My preference has always been to work on the version of node that would be supported by AWS, thus the latest is 4.3. This avoids any unnecessary incompatibility of code.
• There are platform specific differences in execution of command lines and different ones would need to be documented and maintained for each.
• The inspection option in node6 is an experimental feature

I understood the goal to be an easy (I know this to be subjective as well ;o), platform independent mechanism.
So, by just doing something like:
sls-debug offline
You are getting the whole environment up and running, including the firing of the chrome browser on any platform, ready to set breakpoints. For me this makes it easy and fun to use.

Of course, this does work with any serverless command.
sls-debug create --template aws-nodejs

[Bilal-S]

@mikestaub Mike I used your fork to test serverless 1.0alpha and offline together and ran into this error after registering the plugin:
Cannot read property 'start' of undefined
when calling this
serverless offline start
Is this something you encountered? If not, I will try to work through it.

Stack looks like this:
TypeError: Cannot read property 'start' of undefined at PluginManager.validateOptions (~/code/GitHub/serverless/lib/classes/PluginManager.js:56:57) at PluginManager.run (~/code/GitHub/serverless/lib/classes/PluginManager.js:77:10) at Serverless.run (~/code/GitHub/serverless/lib/Serverless.js:77:33) at ~/code/GitHub/serverless/bin/serverless:18:50

Serverless does recognize the presence of the plugin:

Plugins AwsInfo, Create, Deploy, Invoke, Info, Logs, Remove, Tracking, AwsDeploy, AwsInvoke, Package, AwsLogs, AwsRemove, AwsCompileFunctions, AwsCompileScheduledEvents, AwsCompileS3Events, AwsCompileApigEvents, AwsCompileSNSEvents, AwsDeployFunction, Offline

[mikestaub]

start is now a life cycle hook, not a subcommand. Try just 'serverless offline'.

Sorry I should have updated the README as well, let me know if you still have issues. I didn't rigorously test that branch yet.

[dherault]

This plugin is not v1-ready yet. If you want to PR please do. :)

[dherault]

@Bilal-S It's done! Do not hesitate to refactor things as you go along, this project needs it :)

[Bilal-S]

@dherault Thanks :o)

[andythecoderman]

node --debug node_modules/serverless/bin/serverless offline --stage
Then in Webstorm I go to Run -> Edit Configurations, add a new configuration and choose "Node.js Remote Debug". I left all of the default options and clicked OK. Then I click OK on the toolbar and voila, I'm debugging

This works for me in webstorm but only for the first request. I have to restart the process and reattach the debugger after each request. I'm guessing serverless is launching a new child process each time? Any ideas for work-arounds?

[jorenvh1]

Can anyone explain me how you would go about step debugging with sls offline in python?