The --debugOffline flag seems to only print some debug info to console. I would expect that to also send the --debug flag to the node process, so it exposes the debugger listening in the default port (5858), or setting --debug=PORT, to use a custom port, just as it happens with the node command. This way we could use any debugging tool to attach to that port and debug line by line from our code editor.
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?)
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.
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.
just a note that VS code now supports attaching to an existing node session, so you can debug it with vs code
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
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.

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?
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
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.
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
@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
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.
This plugin is not v1-ready yet. If you want to PR please do. :)
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?
@Bilal-S It's done! Do not hesitate to refactor things as you go along, this project needs it :)
@dherault Thanks :o)
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
@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.
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?
@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"
]
}
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.
Can anyone explain me how you would go about step debugging with sls offline in python?
sourceMap
@leobarcellos did you get any luck with these breakpoint configurations?
Most helpful comment
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