VS-Code: Fehler "Haltepunkt ignoriert, weil generierter Code nicht gefunden wurde"


77

Ich habe überall gesucht und habe immer noch Probleme beim Debuggen von TypeScript in VS Code. Ich habe diesen Thread gelesen, aber ich bin immer noch nicht in der Lage, meine Haltepunkte in einer TypeScript-Datei zu erreichen. Das Erreichen der Haltepunkte in .js-Dateien funktioniert einwandfrei.

Hier ist das einfachste "Hallo Welt" -Projekt, das ich eingerichtet habe.

  • 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
            }
        ]
    }
    

Ich habe die js.map-Dateien durch Ausführen des tsc --sourcemap app.tsBefehls generiert .

Nach all diesen Schritten, wenn ich einen Haltepunkt in der console.log(message);Zeile festlege und das Programm (F5) über die Registerkarte "Debug" starte, ist dieser Haltepunkt ausgegraut und lautet "Haltepunkt ignoriert, weil generierter Code nicht gefunden wurde (Quellzuordnungsproblem?)". Ich habe einen Screenshot von dem angehängt, was ich beobachte:

Geben Sie hier die Bildbeschreibung ein

Was vermisse ich?

Bearbeiten:

Hallo, ich bin immer noch dabei. Ich habe es geschafft, ein Beispielprojekt zu erstellen, das die Haltepunkte erreicht hat, aber nachdem ich versucht habe, dieses Projekt an eine andere Stelle auf meiner Festplatte zu kopieren, wurden die Haltepunkte wieder grau und wurden nicht getroffen. Was ich in diesem Testprojekt anders gemacht habe, war die Verwendung von Inline-Quellkarten durch Kompilieren der TypeScript-Dateien mittsc app.ts --inlinesourcemap

Ich habe das erwähnte Beispielprojekt auf GitHub hochgeladen, damit Sie es hier ansehen können .

Antworten:


30

Die Einstellung hat "outFiles" : ["${workspaceRoot}/compiled/**/*.js"]das Problem für mich gelöst.

"outFiles"Wert sollte in einem Satz übereinstimmen tsconfig.jsonfür outDirund mapRootdas ist ${workspaceRoot}in Ihrem Fall, so versuchen"outFiles": "${workspaceRoot}/**/*.js"

Hier sind meine 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"
    ]
}


und 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
        }
    ]
}

Hier ist ein kleines Projekt, in dem möglicherweise alle Parameter https://github.com/v-andrew/ts-template eingestellt sind


3
Vielen Dank! Ich habe einen ganzen Tag lang nach der Lösung für mein Problem gesucht und die Verwendung von outDir mit sourceMaps endlich behoben!
Maksym

Unter Windows VSC mit 8.9.1 1.8.1 und Node.js ich diese Änderungen vornehmen musste launch.json: "outFiles": [],statt outDir": "${workspaceRoot}/compiled",und ich hatte von zu wechseln , "program": "${workspaceRoot}/app.js",um "program": "${workspaceRoot}\\app.js",so \ statt /.
Surfmuggle

17

Ich bin auf diese Frage gestoßen, als ich nach einer Lösung für ein ähnliches Problem gesucht habe, das ich hatte. Obwohl es sich von OPs Problem unterscheidet, könnte es anderen helfen.

Kontext: Ich habe das HelloWorld-Beispiel für Visual Studio-Code befolgt und konnte nicht an Haltepunkten anhalten.

Ich habe mein Problem gelöst, indem ich .vscode/launch.jsondas "sourceMaps": trueAttribut unter der Startkonfiguration so geändert habe (es startet standardmäßig mit false).


3
Bitte beachten Sie: Für mich musste sourceMaps auf true gesetzt werden, aber ich musste auch outFiles setzen, wie in der nächsten Antwort angegeben.
narr4jesus

Hier gilt das gleiche! Ohne hat vscode nur angehalten debugger;(zumindest das. Als Lackmustest zu Beginn ...). - mit "outDir": "${workspaceRoot}/build"auch Haltepunkten funktionieren gut ... (so kann vscode wahrscheinlich keine quellenseitigen Haltepunkte auf der Build-Seite (die es natürlich ausführt) ohne ...)
Frank Nocke

6

Ich denke, das Problem könnte in Ihrem 'Programm'-Bereich von launch.json liegen. Versuchen Sie es so:

{
    // 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}"
}

Ich habe das "Programm": "$ {workspaceRoot} /app.js" in "program": "$ {workspaceRoot} /app.ts" geändert, aber der Haltepunkt in der .ts-Datei wird immer noch nicht erreicht, nur der in Die .js-Datei wird getroffen.
Vladimir Amiorkov

Können Sie der Antwort folgen, die ich im folgenden Beitrag gegeben habe: stackoverflow.com/questions/35606423/… Beginnen Sie mit der Überprüfung der Pfade in der Datei map.js. Es sollte Ihnen helfen, das Problem genau zu bestimmen.
Inmitten

Wenn ich das Beispielprojekt von diesem Thread aus ausführe ( github.com/7brutus7/stackoverflow ), erhalte ich einen Haltepunkt in der .ts-Datei. Leider bin ich total verloren, wie das in diesem Projekt funktioniert und nicht in meinem Sampler-Projekt.
Vladimir Amiorkov

Verwenden Sie in Ihrem ursprünglichen Code lokal installiertes tsc oder globales (überprüfen Sie task.json)? Im vorherigen Thread gab es einige Probleme mit der globalen Instanz.
Inmitten

Ich benutze das globale tsc, in der automatisch generierten Task.json ist es wie folgt eingestellt: "" Befehl ":" tsc "" Die tsc-Version ist 1.8.7
Vladimir Amiorkov

5

Das gleiche Problem konfrontiert und behoben, indem der Pfad zu den .tsDateien korrigiert wurde .
Mein Projekt enthält srcund distdirs und das Problem war, dass die generierten .mapDateien nicht den richtigen Pfad zum srcdir hatten.

Das Update - tsconfig.json:

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

Anfangs zeigte ich sourceRootauf srcund es gibt kein srcVerzeichnis im Inneren dist.

Auch sourceMapssollte nach trueinnen eingestellt werden launch.json.


Dies ist eine gute Zusammenfassung der wichtigsten Themen. sourceMaps in launch.json ist wie angegeben erforderlich, aber ich hatte gerade ein Problem, weil ich meinen "program" -Wert für launch.json so geändert habe, dass er auf eine .js-Datei anstatt auf eine .ts-Datei verweist. VS Code hat Haltepunkt erreicht. Wieder arbeiten! Cheerz!
Jwwishart

Ich habe so viel Zeit damit verbracht, daran zu arbeiten, und Ihr Tipp hat sourceRootsich als die Lösung herausgestellt. Pfui! Ich wünschte, es wäre nicht so schwer, daran zu arbeiten. Ich wünsche mir, wenn Sie tsc --initden mit dem sourceRootFeld verknüpften Kommentar ausführlicher ausführen und erklären, welche Struktur er tatsächlich für die Dateien erwartet, damit Sie herausfinden können, welcher Wert der richtige ist. Auf jeden Fall DANKE!
Michael Tiller

5

Nachdem ich mir den ganzen Tag die Haare ausgerissen hatte, brachte ich sie endlich zum Laufen.

Das Problem ist, dass es drei Dateien gibt, mit denen man herumspielen muss - launch.json, tsconfig.json und webpack.config.js, also ist alles kombinatorisch.

Das DiagnosticLogging war der Schlüssel, um es herauszufinden.

Microsoft macht das bitte einfacher ... Wirklich, vscode hätte das herausfinden oder mich zumindest mehr über den Prozess führen können.

Wie auch immer, hier ist, was in meinem Start endlich funktioniert hat.

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

meine tsconfig.json:

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

meine 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",

Vielen Dank für das Teilen, aus irgendeinem Grund musste ich auch diesen sourceMapPathOverride hinzufügen.
M. Herold

3
diagnosticLoggingist jetzt veraltet ... tracestattdessen verwenden.
Lucas

3

Das gleiche Problem wurde behoben, indem die "webRoot"Konfiguration in launch.json korrigiert wurde. Hier ist die Explorer-Ansicht meines Arbeitsbereichs.

Da sich das Kompilierungsergebnis main.js and main.js.mapim "./project/www/build"Verzeichnis befindet, ändere ich den "webRoot"Eintrag in "${workspaceRoot}/project/www/build"von "${workspaceRoot}"und es hat funktioniert!

Die Datei launch.json lautet wie folgt:

{
    "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"
        }
    ]
}

Vielen Dank für die Lösung, die mir bei der Lösung meines Problems geholfen hat. Ich wurde zunehmend frustriert, da die Haltepunkte nicht erkannt wurden.
LearnToLive

@LearnToLive, ich freue mich zu hören, dass Sie Ihr Problem gelöst haben. Und ich möchte mich bei Ihnen dafür bedanken, dass Sie mir geholfen haben, mein erstes Abzeichen zu verdienen.
Hope Sun

2

Update: Das TypeScript-Debugging wurde jetzt in 0.3.0 hinzugefügt. Update: Löschen Sie immer Ihre Haltepunkte, hängen Sie sie an und fügen Sie dann Haltepunkte hinzu. Dies ist ein Fehler und wurde gemeldet.


2

Keine der anderen Antworten hat bei mir funktioniert.

Ich habe dann festgestellt, dass das programAttribut in meinem launch.jsonauf die .jsDatei zeigt, aber mein Projekt ist ein TypeScript-Projekt.

Ich habe es so geändert, dass es auf die TypeScript ( .ts) - Datei verweist , und das outFilesAttribut so festgelegt, dass es darauf verweist, wo sich der kompilierte Code befindet:

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

Dies löste das Problem für mich!


1

Es gibt wirklich nur einen Weg, dies zu beheben, nämlich den tatsächlich verwendeten Quellkartenpfad zu betrachten.

Fügen Sie die folgende Zeile hinzu launch.json:

"diagnosticLogging": true,

Ihre Konsole enthält unter anderem folgende Zeilen:

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

Und dann optimieren Sie einfach Ihren sourceMapPathOverridesPfad, um ihn an Ihren tatsächlichen Quellpfad anzupassen. Ich habe festgestellt, dass ich für verschiedene Projekte eine etwas andere Konfiguration benötigte, daher hat es mir sehr geholfen zu verstehen, wie man dies debuggt.


1

Nachdem viel Zeit für die Behebung dieses Problems verschwendet wurde, stellte sich heraus, dass der Debugging-Trace am besten durch Hinzufügen der folgenden Zeile in launch.json aktiviert werden kann.

"trace": true

Und sehen Sie, wo das Problem tatsächlich liegt. Ihre Debug-Konsole gibt Folgendes aus:

Verbose logs are written to: /Users/whatever/Library/Application Support/Code/logs/blah/blah/debugadapter.txt

Ihre Konsole enthält unter anderem folgende Zeilen:

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

Verwenden Sie sourceMapPathOverride, um das Problem so zu beheben, dass es tatsächlich Ihrem Pfad entspricht. Die Eigenschaft "trace" hieß früher "diagnostisches Protokollieren" und wird nicht mehr verwendet.


1

Ich habe meine Konfiguration in launch.json geändert für:

{ "name": "Debug tests in Chrome", "type": "chrome", "request": "attach", "port": 9222, "sourceMaps": true, "sourceMapPathOverrides": { "*": "${webRoot}/*" }, "webRoot": "${workspaceRoot}" }

vorher war:

{ "name": "Debug tests in Chrome", "type": "chrome", "request": "attach", "port": 9222, "sourceMaps": true, "webRoot": "${workspaceRoot}" }

Include "sourceMapPathOverrides" war meine Lösung



0

Diese Konfiguration in launch.json funktionierte:

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


0

Ich möchte dazu beitragen, einige Stunden Kopfschlag zu sparen.

Ich habe Debugger für Chrome für VS-Code verwendet (Sie benötigen dies nicht für Webstorm). Ich würde empfehlen, 10 Minuten mit dem Lesen der Seite zu verbringen. Dies wird Ihre Welt aufklären.

Stellen Sie nach der Installation der Debugger-Erweiterung sicher, dass Source-Map installiert ist. In meinem Fall benötigte ich auch Source-Map-Loader . Überprüfen Sie Ihre package.json darauf.

Meine launch.json, die die Chrome-Debugger-Konfiguration ist (alle meine Quelldateien waren unter 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}/*"
      }
    }
  ]
}

Fügen Sie devtool: 'source-map'Ihrer webpack.config.js hinzu. Andere Parameter, die Mapping-Inlines generieren, funktionieren mit Chrome Debugger nicht (sie erwähnen dies auf ihrer Seite).

Dies ist ein Beispiel:

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
};

Dann führen Sie Ihr Webpack aus: `webpack-dev-server --devtool source-map --progress --port 8080, ich habe webpack-dev-server verwendet, aber es hat die gleichen Optionen wie webpack.

Wenn Sie dies tun, müssen Sie eine .map- Datei Ihrer generierten App sehen. Wenn nicht, kommen Sie zurück und überprüfen Sie Ihr Setup.

Wechseln Sie nun in VS Code zur Debug-Konsole und führen Sie sie aus .scripts. Dies ist ein sehr nützlicher Befehl, da er Ihnen zeigt, welcher generierte Code welcher Quelle zugeordnet ist.

Etwas wie das: - webpack:///./src/stores/friendStore.js (/Users/your_user/Developer/react/tutorial/src/stores/friendStore.js)

Wenn dies falsch ist, müssen Sie Ihre sourceMapPathOverrides in Ihrer launch.json überprüfen. Beispiele finden Sie auf der Seite der Erweiterung


0

Ja! In meinem Fall, wenn Sie dies in der Datei launch.json ändern, wird das Problem behoben:

  "sourceMapPathOverrides": {
    "webpack:///./~/*": "${webRoot}/node_modules/*",
    "webpack:///./*":   "${webRoot}/*",
    "webpack:///*":     "*",
    "webpack:///src/*": "${webRoot}/*",
  }

0

Bei Verwendung von Angular habe ich festgestellt, dass ich mein Ordnerverzeichnis immer auf den srcOrdner zeige. Auf diese Weise ist mein Arbeitsbereich nicht so voll mit Stammdateien, die ich nie benutze. Dies hat mir in der Vergangenheit jedoch einige Probleme bereitet, insbesondere bei der Verwendung von VSCode, da mir viele der Funktionen scheinen, die Ordnerstruktur zu überprüfen und von dort aus Ihre Dateien auszuführen. (Erwarten Sie einige der fehlenden Dateien)

Ich hatte genau das gleiche Problem mit dieser Fehlermeldung, und als ich aus früheren Erfahrungen lernte, stellte ich fest, dass ich mein Projekt einen Ordner tief anstelle des <app name>Stammordners öffnete . Also habe ich mein Projekt einfach geschlossen und einen Ordner geöffnet (damit alle anderen Dateien auch in der Ordnerstruktur enthalten sind) und mein Problem wurde sofort behoben.

Ich glaube auch, dass viele der oben genannten Antworten zum Ändern Ihrer Dateien und Ordnerstruktur Problemumgehungen für dieses Problem sind, Ihr Arbeitsprojekt nicht im Stammordner zu öffnen, unabhängig davon, welches Framework / welche Sprache Sie verwenden.


0

Ich musste nur meinen Express-Server neu starten und dann den Debugger erneut anschließen.


-2

Wenn Sie zu einem Skriptprojekt vom Typ Visual Studio wechseln, können Sie ts-Dateien normalerweise debuggen. Ich denke, das Problem in der App.js.map-Generierungsdatei hier ist ein Beispiel aus Visual Studio app.js.map

{"version": 3, "file": "app.js", "sourceRoot": "", "sources": ["app.ts"], "names": ["HelloWorld", "HelloWorld.constructor" ], "Abbildungen": "AAAA; IACIA, oBAAmBA, OAAcA; QAAdC, YAAOA, GAAPA, OAAOA, CAAOA; IAEjCA, CAACA; IACLD, iBAACA; AAADA, CAACA, AAJD, IAIC; AAED, IAAI, KAAK , UAAU, CAAC, kBAAkB, CAAC, CAAC; AAC / C, OAAO, CAAC, GAAG, CAAC, KAAK, CAAC, OAAO, CAAC, CAAC "}

vs Visual Studio Code app.js.map

{"version": 3, "file": "app.js", "sourceRoot": "", "sources": ["../ app.ts"], "names": [], "mappings": AACA; IACI, oBAAmB, OAAc; QAAd, YAAO, GAAP, OAAO, CAAO; IAEjC, CAAC; IACL, iBAAC; AAAD, CAAC, AAJD, IAIC; AACD, IAAI, KAAK, GAAC, IAAI, UAAU, CAAC, aAAa , CAAC, CAAC, AACxC, OAAO, CAAC, GAAG, CAAC, KAAK, CAAC, OAAO, CAAC, CAAC, AAC3B, OAAO, CAAC, GAAG, CAAC, OAAO, CAAC, CAAC "}

Versuchen Sie es zu ersetzen und versuchen Sie es erneut. Vergessen Sie nicht, die Verzeichnishierarchie der Quellen zu berücksichtigen

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.