3

I am starting to create a project in serverless, this project uses the serverless webpack plugin. As it stands we hooked babel through webpack, and now we want to debug it preferrably in vs code.

our file structure stands: dist:

 |- babelExample.js |- babelExample.js.map |- converse.js |- converse.js.map 

we set the webpack.config.js

var path = require('path'); const webpack = require('webpack'); module.exports = { devtool: "source-map", debug: true, entry: { babelExample: 'example/babelExample.js', converse: 'converse/converse.js' }, target: 'node', plugin: [ new webpack.DefinePlugin({ '__DEV__': true }), new webpack.HotModuleReplacementPlugin(), ], module: { loaders: [ { test: /\.js$/, loaders: ['babel'], include: __dirname, exclude: /node_modules/ }, { test: /\.json$/, loader: 'json-loader' } ] }, output: { devtoolModuleFilenameTemplate: info => { return `${info.resourcePath}?${info.loaders}` }, libraryTarget: 'commonjs', path: path.join(__dirname, 'dist'), filename: '[name].js' }, resolve: { root: [ path.resolve(__dirname), path.resolve(__dirname, 'server'), ], extensions: ['', '.js', '.jsx'] } }; 

our launch.json

{ "type": "node", "request": "launch", "name": "Serve webcast", "program": "/Users/edevh46/.nvm/versions/node/v4.3.2/lib/node_modules/serverless/bin/serverless", "cwd": "${workspaceRoot}", "args": [ "webpack", "serve" ], "preLaunchTask": "build", "runtimeArgs": [ "--nolazy" ], "outFiles": [ "${cwd}/dist/**/*.js" ], "sourceMaps": true, "smartStep": true }, 

When we start serverless webpack, it looks rightly so at the dist folder js generated files, however for breakpoints to work we have to breakpoint the generated file, which then causes the correct source to be displayed.

It seems to me that the paths, are not being correctly satisfied inside vs code, to the specific file.

looking at the maps file:

{"version":3,"sources":["webpack/bootstrap cfe5ab77d9ed3f728d29?undefined","./server/example/babelExample.js?undefined","./~/babel-runtime/core-js/promise.js?undefined","./~/core-js/library/fn/promise.js?undefined","./~/core-js/library/modules/es6.string.iterator.js?undefined","./~/core-js/library/modules/_string-at.js?undefined","./~/core-js/library/modules/_to-integer.js?undefined","./~/core-js/library/modules/_defined.js?undefined","./~/core-js/library/modules/_iter-define.js?undefined","./~/core-js/library/modules/_library.js?undefined","./~/core-js/library/modules/_export.js?undefined","./~/core-js/library/modules/_global.js?undefined","./~/core-js/library/modules/_core.js?undefined","./~/core-js/library/modules/_ctx.js?undefined","./~/core-js/library/modules/_a-function.js?undefined","./~/core-js/library/modules/_hide.js?undefined","./~/core-js/library/modules/_object-dp.js?undefined","./~/core-js/library/modules/_an-object.js?undefined","./~/core-js/library/modules/_is-object.js?

and further down:

"file":"babelExample.js","sourcesContent":[" \t// The module cache\n \tvar installedModules = {};\n\n \t// The require function\n \tfunction webpack_require(moduleId) {\n\n \t\t// Check if module is in cache\n \t\tif(installedModules[moduleId])\n \t\t\treturn installedModules[moduleId].exports;\n\n \t\t// Create a new module (and put it into the cache)\n \t\tvar module = installedModules[moduleId] = {\n \t\t\texports: {},\n \t\t\tid: moduleId,\n \t\t\tloaded: false\n \t\t};\n\n \t\t// Execute the module function\n \t\tmodules[moduleId].call(module.exports, module, module.exports, webpack_require);\n\n \t\t// Flag the module as loaded\n \t\tmodule.loaded = true;\n\n \t\t// Return the exports of the module\n \t\treturn module.exports;\n \t}\n\n\n \t// expose the modules object (webpack_modules)\n \t__webpack_require__.m = modules;\n\n \t// expose the module cache\n \t__webpack_require__.c = installedModules;\n\n \t// webpack_public_path\n \t__webpack_require__.p = \"\";\n\n \t// Load entry module and return exports\n \treturn webpack_require(0);\n\n\n\n// WEBPACK FOOTER //\n// webpack/bootstrap cfe5ab77d9ed3f728d29","'use strict';\nconst createResponse = require('../lib/createResponse');\n\n\nexport const hello = (event, context, cb) => {\n console.log('SERVER this');\n const p = new Promise((resolve, reject) => {\n
resolve('success');\n });\n p\n .then(r => cb(null, {\n
message: 'Go Serverless Webpack (Babel) v1.0! Your function executed successfully!',\n event,\n }))\n .catch(e => cb(e));\n};\n\n\n// WEBPACK FOOTER //\n// ./server/example/babelExample.js","module.exports

I am only new at matching sourcemaps, but i would appreciate if anyone could help understand why i have to breakpoint the generated file and not the original one.

I have tried node2 --inspect but in there breakpointing was completely broken, which leads me to believe that there is something missing to help resolve the path, back to original file.

Any help would be appreciated.

4
  • 1
    Try node2 again - this probably won't work with 'node' because webpack does weird stuff. Check the node2 readme for tips - github.com/Microsoft/vscode-node-debug2#the-scripts-command - and use the .scripts command to figure out what the problem is, and add a sourceMapPathOverrides entry if needed. Commented Feb 9, 2017 at 1:45
  • I will tomorrow, just a quick question to use node2 i have to use node v7.x (i was on v7.5.0) but lambda uses v4.3.2, is it reasonable to trust entirely in babel to generate stable code for v4.3.2?? AlsoI had another read about sourcemaps in vs code, and i replaced the paths for an absolute path, and this time in sources i have a full valid path, and yet the result is the same:(... the thing is i have seen numerous examples of webpack source map working vscode, which leads me to believe that maybe i am missing something. Commented Feb 9, 2017 at 1:51
  • @RobLourens yeah changing back to node2 and using absolutePaths seems to allow me to set breakpoints in vs code, although this feature seems a little flacky. Would you know what is the difference between sourcemaps expected by node --inspect and those in vs code debugger?? I am a bit worried that using a different runtime from the one in amazon lambda will cause problems in the future. Commented Feb 9, 2017 at 9:11
  • You can open an issue on github if you want, describing exactly how it's flaky. VS Code uses whatever version of Node is on your computer. I don't know what version Lambda has, or what else might be different there. Commented Feb 9, 2017 at 18:31

1 Answer 1

3

after playing a bit longer with the output section, i found out that if i add:

devtoolModuleFilenameTemplate: '[absolute-resource-path]', devtoolFallbackModuleFilenameTemplate: '[absolute-resource-path]?[hash]', 

to the output section vs code can now find the breakpoints properly using node process.

Sign up to request clarification or add additional context in comments.

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.