VS Code: error "breakpoint is ignored because the generated code was not found"

Question

I looked all over the place and I still have TypeScript debugging inside VS code. I read this thread, but still I can’t hit my breakpoints placed inside the TypeScript file, hitting breakpoints in .js files, everything works fine.

So, here is the easiest hello world project I created.

• app.ts:

  var message: string = "Hello World"; console.log(message); 

• tsconfig.json

   { "compilerOptions": { "target": "es5", "sourceMap": true } } 

• launch.json

   { "version": "0.2.0", "configurations": [ { "name": "Launch", "type": "node", "request": "launch", "program": "${workspaceRoot}/app.js", "stopOnEntry": false, "args": [], "cwd": "${workspaceRoot}", "preLaunchTask": null, "runtimeExecutable": null, "runtimeArgs": [ "--nolazy" ], "env": { "NODE_ENV": "development" }, "externalConsole": false, "sourceMaps": true, "outDir": null } ] } 

I created js.map files by running the tsc --sourcemap app.ts .

After all these steps, when I set a breakpoint in the line console.log(message); and I run the program (F5) from the Debug tab, the breakpoint is grayed out, saying: "The breakpoint is ignored because the generated code was not found (is there a problem with the source map?)." I have attached a screenshot of what I am observing:

What am I missing?

Edit:

Hi, I still stick with this. I managed to create one sample project that fell on breakpoints, but after I tried to copy this project to another location on my hard drive, the breakpoints turned gray again and did not suffer. In this test project, I used different built-in source files, compiling TypeScript files with tsc app.ts --inlinesourcemap

I uploaded the sample project mentioned on GitHub so you can look at it here .

Answer 1

Setting "outFiles": ["${workspaceRoot}/compiled/**/*.js"], solved the problem for me.

The value "outFiles" should correspond to one set in tsconfig.json for outDir and mapRoot , which in your case is equal to ${workspaceRoot} , so try "outFiles": "${workspaceRoot}/**/*.js"

Here is my tsconfig.json

 { "compilerOptions": { "module": "commonjs", "noImplicitAny": true, "removeComments": true, "preserveConstEnums": true, "sourceMap": true, "target": "es6", "outFiles": ["${workspaceRoot}/compiled/**/*.js"], "mapRoot": "compiled" }, "include": [ "app/**/*", "typings/index.d.ts" ], "exclude": [ "node_modules", "**/*.spec.ts" ] } 

and launch.json

 { "version": "0.2.0", "configurations": [ { "type": "node", "request": "launch", "name": "Launch Program", "program": "${workspaceRoot}/compiled/app.js", "cwd": "${workspaceRoot}", "outDir": "${workspaceRoot}/compiled", "sourceMaps": true } ] } 

Answer 2

I came across this question, looking for a solution to the same problem as mine. Although it is different from an OP problem, it can help others.

Context: I followed the Visual Studio Code HelloWorld code example and was unable to stop at break points.

I solved my problem by changing .vscode/launch.json so that the attribute "sourceMaps": true in the Launch setting was set (it starts by default to false).

Answer 3

I think the problem may be in the "program" section for launch.json. Try this as follows:

 { // Name of configuration; appears in the launch configuration drop down menu. "name": "Launch", // Type of configuration. "type": "node", "request": "launch", // Workspace relative or absolute path to the program. "program": "${workspaceRoot}/app.ts", // Automatically stop program after launch. "stopOnEntry": false, // Command line arguments passed to the program. "args": [], // Workspace relative or absolute path to the working directory of the program being debugged. Default is the current workspace. "cwd": "${workspaceRoot}", // Workspace relative or absolute path to the runtime executable to be used. Default is the runtime executable on the PATH. "runtimeExecutable": null, // Optional arguments passed to the runtime executable. "runtimeArgs": ["--nolazy"], // Environment variables passed to the program. "env": { "NODE_ENV": "development" }, // Use JavaScript source maps (if they exist). "sourceMaps": true, // If JavaScript source maps are enabled, the generated code is expected in this directory. "outDir": "${workspaceRoot}" } 

Answer 4

After tearing my hair all day, I finally got it to work.

The problem is that the three files for the script are launch.json, tsconfig.json and webpack.config.js, so all are combinatorial.

The diagnostic log was the key to helping me figure it out.

Microsoft, please make it simpler ... Indeed, vscode could have figured this out, or at least directed me more to the process.

Anyway, here is what finally worked in my launch.json:

 "url": "http://localhost:8080/", "sourceMaps": true, "webRoot": "${workspaceRoot}", "diagnosticLogging": true, "sourceMapPathOverrides": { "webpack:///src/*": "${workspaceRoot}/src/*" } 

my tsconfig.json:

 "outDir": "dist", "sourceMap": true 

my webpack.config.js:

 output: { path: 'dist/dev', filename: '[name].js' }, ... module: { loaders: [...], preLoaders: [{ test: /\.js$/, loader: "source-map-loader" }] } ... plugins: [ new webpack.SourceMapDevToolPlugin(), ... ], devtool: "cheap-module-eval-source-map", 

Answer 5

Building on the same problem and solving it, fixing the path to the .ts files.
My project contains src and dist dirs, and the problem was that the generated .map files did not have the correct path to the src directory.

Fix - tsconfig.json :

 { "compilerOptions": { "target": "es5", "module": "commonjs", "sourceMap": true, "outDir": "dist", "sourceRoot": "../src" } } 

Initially my sourceRoot pointing to src and there was no src dir inside dist .

In addition, sourceMaps must be set to true inside launch.json .

Answer 6

Update: TypeScript now added debugging in 0.3.0. Update: always clear breakpoints, then attach, and then add breakpoints. This is the error reported.

Answer 7

Relying on the same problem and solving it, fixing the "webRoot" config in launch.json. Here is my view of the workspace explorer.

Since the compilation result of main.js and main.js.map is in the "./project/www/build" directory, I change the entry "webRoot" to "${workspaceRoot}/project/www/build" from "${workspaceRoot}" and it worked!

The launch.json file is as follows:

 { "version": "0.2.0", "configurations": [ { "name": "Launch Chrome against localhost", "type": "chrome", "request": "launch", "url": "http://localhost:8100", "sourceMaps": true, "webRoot": "${workspaceRoot}/project/www/build" }, { "name": "Attach to Chrome", "type": "chrome", "request": "attach", "port": 9222, "url": "http://localhost:8100", "sourceMaps": true, "webRoot": "${workspaceRoot}/project/www/build" } ] } 

Answer 8

None of the other answers worked for me.

Then I realized that the program attribute in my launch.json pointing to a .js file, but my project was a TypeScript project.

I modified it to point to a TypeScript file ( .ts ), and set the outFiles attribute to indicate where the compiled code lives:

 { "type": "node", "request": "launch", "name": "Launch Program", "program": "${workspaceRoot}/src/server/Server.ts", "cwd": "${workspaceRoot}", "outFiles": ["${workspaceRoot}/dist/**/*.js"] } 

This solved the problem for me!

Answer 9

 outFiles": ["${workspaceRoot}/compiled/**/*.js"], 

It saved my life because TS was not looking for sub-dirs. Thank you very much

Answer 10

There is only one way to resolve this, and that is to look at the path of the source map that is actually used.

Add the following line to launch.json :

 "diagnosticLogging": true, 

Among many other things, the console will have the following lines:

 SourceMap: mapping webpack:///./src/main.ts => C:\Whatever\The\Path\main.ts, via sourceMapPathOverrides entry - "webpack:///./*": "C:/Whatever/The/Path/*" 

And then you just tweak your sourceMapPathOverrides so that the path matches your source path. I found that I needed a slightly different configuration for different projects, so understanding how to debug this really helped.

Answer 11

Late to the party, but you can check this post on github Check globbing support for the outFiles attribute in launch configuration # 12254 .

Basically in the new version of vscode you should now use the glob template with the outFiles property in your task.json.

I had a simlar problem. I fixed by specifying the output disk with outFiles

Answer 12

This configuration in the launch.json file:

{ "type": "node", "request": "launch", "name": "Launch Program - app", "program": "${workspaceRoot}/src/server.ts", "cwd": "${workspaceFolder}", "outFiles": ["${workspaceRoot}/release/**"], "sourceMaps": true }

Answer 13

I would like to do my part to take care of a few hours of head banging.

I used the Debugger for Chrome for VS-code (you do not need it for webstorm), I would recommend spending 10 minutes reading a page , it will enlighten your world.

After installing the debugger extension, make sure that the source card is installed, in my case I also needed the source map loader. Check package.json .

My launch.json, which is a chrome debugger configuration (all my source files in which src ):

 { // 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": "chrome", "request": "attach", "name": "Attach to Chrome", "port": 9222, "webRoot": "${workspaceRoot}/src" }, { "type": "chrome", "request": "launch", "name": "Launch Chrome against localhost", "url": "http://localhost:8080", "webRoot": "${workspaceRoot}/", "sourceMapPathOverrides": { "webpack:///./*": "${webRoot}/*" } } ] } 

Add devtool: 'source-map' to your webpack.config.js. Other options that generate a string display will not work with Chrome Debugger (they mention this on their page).

That's an example:

 module.exports = { entry: "./src/index.js", output: { path: path.resolve(__dirname, "build"), filename: "bundle.js" }, plugins: [ new HtmlWebpackPlugin({ title: "Tutorial", inject: "body", template: "src/html/index.html", filename: "index.html" }), new DashboardPlugin() ], devtool: 'source-map', module: { loaders: [ { test: /\.css$/, loader: "style-loader!css-loader" }, { test: /\.js?$/, exclude: /(node_modules|bower_components)/, loader: "babel-loader", query: { presets: ["es2017", "react"], plugins: ['react-html-attrs'] } } ] }, watch: true }; 

Then you run your web package: `webpack-dev-server --devtool source-map --progress --port 8080, I used webpack-dev-server, but it has the same parameters as webpack.

When you do this, you will see the .map file of the created application. If not, go back and check your setup.

Now in VS Code, go to Debug Console and run .scripts . This is a very useful command because it shows you which generated code maps to which source.

Something like this: - webpack:///./src/stores/friendStore.js (/Users/your_user/Developer/react/tutorial/src/stores/friendStore.js)

If this is not the case, you must confirm your sourceMapPathOverrides in your .json start, examples are available on the extension page

Answer 14

If you switch to the visual studio type script project, you can properly debug the ts files. I think the problem is in the app.js.map generation file, here is a sample from the visual studio app.js.map

{"version": 3, "file": "app.js", "sourceRoot": "," sources ": [" app.ts "]," names ": [" HelloWorld "," HelloWorld.constructor "] , "display": "AAAA; IACIA, oBAAmBA, OAAcA; QAAdC, YAAOA, GAAPA, OAAOA, CAAOA; IAEjCA, CAACA; IACLD, iBAACA; AAADA, CAACA, AAJD, IAIC; AAED, IAAI, Kaak, The Hague, IAAI, UAAU, DVK, kBAAkB, DVK, ; AAC / C, OAAO, DCK, The Hague, DCK, Kaak, DCK, OAAO, DVK, Far-Eastern Military Complex "}

vs visual studio code app.js.map

{"version": 3, "file": "app.js", "sourceRoot": "," sources ": [" .. /app.ts "]," names ": []," display ":" AACA; IACI, oBAAmB, OAAc; QAAd, YAAO, GAAP, OAAO, CAAO; IAEjC, DCK; IACL, iBAAC; AAAD, DVK, AAJD, IAIC; AACD, IAAI, Kaak, GAAC, IAAI, UAAU, DZVK, AAAA, DVK, DZVK; AACxC, OAAO, DVK, The Hague, DVK, Kaak, DVK, OAAO, DVK, ; AAC3B, OAAO, DVK, The Hague, DVK, OAAO, DVK, "}

try replacing it and try again, do not forget to consider the hierarchy of source directories