webentwicklung-frage-antwort-db.com.de

VS Code Unverifizierte Haltepunkte

Ich versuche, eine Node/Express TypeScript-App in VS-Code (Version 1.24.0) zu debuggen, und alle meine Haltepunkte werden während des Debuggens grau dargestellt.

Der Fehler ist "Unverifizierter Haltepunkt, Haltepunkte gesetzt, aber noch nicht gebunden." Ich habe gesucht, kann aber nicht herausfinden, was mit meiner Konfiguration falsch ist. Es ist kein Fehler in der Konsole vorhanden. Der Debugger wird bei der Auswahl des Prozesses erfolgreich angefügt. Die Haltepunkte funktionieren jedoch nicht.

Wie debugge ich das?

grundlegende Ordnerstruktur:

/.vscode
/src/server.ts
/dist/server.js
launch.json
tsconfig.json

launch.json

{
            "type": "node",
            "request": "attach",
            "name": "Attach by Process ID",
            "processId": "${command:PickProcess}",
            "protocol": "inspector",
            "address": "localhost",
            "port": 8080,
            "restart": true,
            "preLaunchTask": "npm: build",
            "sourceMaps": true,
            "outFiles" : [ "${workspaceFolder}/dist/**/*.js" ]
        },

tsconfig.json

{
  "compilerOptions": {
    "alwaysStrict": true,
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "module": "commonjs",
    "moduleResolution": "node",
    "target": "es6",
    "outDir": "dist",
    "rootDir": "src",
    "sourceMap": true,
    "typeRoots": [ "node_modules/@types" ]
  },
  "include": [
    "src/**/*.ts"
  ],
  "exclude": [
    "node_modules"
  ]
}

aufgaben.json

"version": "2.0.0",
    "tasks": [
        {
            "type": "npm",
            "script": "build",
            "group": {
                "kind": "build",
                "isDefault": true
            }
        } ]
3
beachCode

Für jeden, der auf diesen Fehler stößt, konnte ich eine Lösung finden. Das Problem war die Art und Weise, wie ich den Node-Prozess startete, nicht die Zuordnung der Quellkarten (was einen anderen Fehler verursacht).

Um eine Verbindung zu dem Prozess herzustellen, habe ich ihn wie folgt vom VS-Code-Terminal aus gestartet: 

node --inspect dist/server.js

launch.json:

{
            "type": "node",
            "request": "attach",
            "name": "Attach by Process ID",
            "processId": "${command:PickProcess}",
            "protocol": "inspector",
            "address": "localhost",
            "port": 8080,
            "restart": true,
            "preLaunchTask": "npm: build",
            "sourceMaps": true,
            "outFiles" : [ "${workspaceRoot}/dist/**/*.js" ]
        },
3
beachCode

Ich fand, dass alle Haltepunkte, die ich in einer Datei festlegen wollte, dieses Problem aufwiesen, aber nicht der Rest. 

Ich benannte die Datei dispatcher.js mit einem Kleinbuchstaben, zog sie jedoch mit folgenden Knoten in den Knoten

const { Dispatcher } = require('./Dispatcher')

und der Inhalt war eine Javascript-Klasse, die exportiert wurde als:

module.exports = { Dispatcher }
0
Dr.YSG

Ich habe dieses Problem heute bekommen, ich habe versucht, den Debugger neu zu erstellen und erneut auszuführen. Ich habe alle VS-Code-Instanzen heruntergefahren und neu gestartet und arbeite jetzt.

0
MattG

Dieses Problem ist bei der Verwendung von vscode 1.25 aufgetreten

Sieht aus wie es ausgelöst wird, wenn eine Haltepunkt-haltige Quelle (.ts) geändert wird, während die Debug-Sitzung ausgeführt wird. Die Haltepunkte können durch erneutes Speichern der Quelle oder durch erneutes Umschalten des Haltepunkts wieder aktiviert werden.

Wenn jedoch die Quelle geändert wurde, muss das Debugging neu gestartet werden, um mit der Quelle synchron zu sein.

Dieses Problem scheint auch in den Editiermodus überzugehen. Die Haltepunkte bleiben auch nach dem Verlassen des Debugmodus "Unverified". Erneut scheint das erneute Speichern der Quelle die Haltepunkte in diesem Fall wieder zu aktivieren. 

0
omnivorosaur

Ich hatte ein identisches Problem. Wenn ein Fehler vorhanden war, meldete der Debugger den Fehler, aber wenn kein Fehler auftrat, wurde er an Haltepunkten nicht angehalten. Die für mich beschlossene Änderung bestand darin, den genauen Dateinamen anzugeben, der anstelle von localhost bereitgestellt werden würde. Zum Beispiel würde auf NodeJS Express die Angabe von localhost:3000 nicht bei meinen Haltepunkten aufhören, sondern localhost:3000/index.html funktionierte wie erwartet

Vollständige Konfiguration, die wie erwartet an Haltepunkten aufhört (bis heute):

Mein Ordner ist in VSCode geöffnet: learningPixi mit vollständigem Ordner (Ubuntu Linux): /home/leigh/node/pixi-tut/learningPixi

Meine Ordnerstruktur ist:

/home/leigh/node/pixi-tut/learningPixi/.vscode/launch.json /home/leigh/node/pixi-tut/learningPixi/public/index.html /home/leigh/node/pixi-tut/learningPixi/server.js

Inhalt meiner launch.json-Datei:

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "chrome",
      "request": "launch",
      "name": "Launch Chrome against localhost",
      "url": "http://localhost:3000/index.html",
      "webRoot": "${workspaceFolder}/public",
      "skipFiles": ["pixi.min.js"]
    }
  ]
}

"skipFiles" war auch sehr nützlich, da ansonsten der Debugger in jeden Funktionsaufruf eintritt

Meine (sehr grundlegende) Express-Server-Konfiguration nur zum Debuggen von JavaScript in statischen Dateien war:

const express = require('express');
const path = require('path');

const app = express();
app.use(express.static(path.join(__dirname, '/public')));
app.listen(3000, () => console.log('App started on port 3000'));

Und gemäß der obigen Ordnerstruktur müssen Sie sicherstellen, dass sich index.html im Ordner/public befindet

Wenn Sie JavaScript in einer HTML-Datei debuggen, müssen Sie möglicherweise auch die Einstellungen in VSCode aufrufen und Folgendes aktivieren: Haltepunkte überall zulassen

0
Leigh Mathieson

Für zukünftige Leser: Ich bin auf dieses Problem gestoßen, weil ich vor dem Debuggen einen Prod Build meiner App ausgeführt hatte. Der Prod-Build entfernt die Quellkarten, die VS Code zum erfolgreichen Debuggen benötigt. Daher habe ich einen Dev-Build meiner App ausgeführt und dann das Debuggen ausgeführt, und alles hat wie erwartet funktioniert.

0
Fillip Peyton