Protractor: Element Explorer funktioniert nicht auf Node 8

Ich glaube nicht, dass wir derzeit gegen Knoten 8 testen, daher ist es sinnvoll, dass dies möglicherweise defekt ist. Danke, dass du das ansprichst!

Ich werde versuchen, das in den nächsten Tagen zu untersuchen, aber eine PR, um dies zu beheben, wäre sehr willkommen!

_debugger und der Legacy-CLI-Debugger wurden in Node 8 entfernt: https://github.com/nodejs/node/commit/90476ac6ee

Irgendwelche Updates dazu?

Könnten wir bitte wissen, was die Pläne für die Unterstützung von Node 8 sind? :)

Da Node v8 im Oktober in LTS eintreten soll, könnten wir vielleicht ein Update bekommen?

https://github.com/nodejs/LTS#lts -schedule1

Laut https://nodejs.org/en/docs/guides/debugging-getting-started/#legacy -debugger ,
Das node.js-Team migriert Benutzer zur neuen inspect-API.

Gibt es Pläne des Teams, dies entweder mit der inspect-API oder einem anderen Ansatz wieder zum Laufen zu bringen?

Gleicher Fehler https://github.com/node-inspector/node-inspector/issues/1025#issuecomment -339202842
4 Monate schon

Auch https://stackoverflow.com/questions/44662442/node-inspector-not-starting

Ich habe angefangen, mir das anzuschauen. Hier sind eine Reihe von Vermutungen, wie die Aktualisierung funktionieren könnte:

Soweit ich das beurteilen kann, müssen die Änderungen in debuggerCommons.js erfolgen

Anstelle von require('_debugger'); muss require('inspector'); ( Dokumente hier ). Sie können dann den Inspektor öffnen, eine Sitzung erstellen, eine Verbindung herstellen und dann session.post und das Chrome DevTools-Protokoll verwenden , um die Nachrichten zum Hinzufügen der Haltepunkte zu senden.

Wenn ich Zeit habe, werde ich mal eine PR machen.

@phenomnomnominal Hey, das ist großartig! Darf ich wissen, wann Sie für die PR zur Verfügung stehen? Da diese Funktionalität so nützlich ist, wäre es toll, wenn sie bald erstellt werden kann. Es wird unsere Entwicklung so beschleunigen.
Vielen Dank!

@phenomnomnominal Hallo, wir planen, vor kurzem Node 8.0 zu unterstützen. Was ist Ihr aktueller Plan zur Behebung dieses Problems?

Nur das, was ich oben beschrieben habe. Ich hatte mir vorgenommen, heute Abend mal reinzuschnuppern.

@phenomnomnominal das ist großartig, vielen Dank!

@phenomnomnomial Hallo, irgendwelche Updates bisher?

Ich habe angefangen, es zu versuchen, aber ich hatte Probleme mit Selenium, als ich versuchte, die Tests durchzuführen (Irgendwelche Tipps?). Dienstagabend habe ich noch etwas Zeit. Die neue API ist ganz anders, aber ich sehe keine wirklichen Probleme.

Ok, vielen Dank. Ab Montag soll ich noch etwas Zeit haben, vielleicht kann ich mir das auch danach anschauen.

Ich habe... irgendwo? Es stellte sich heraus, dass das Debuggen des Debuggers nicht so einfach ist, wie ich gehofft hatte. @qiyigg hattest du die Gelegenheit, dir etwas anzuschauen?

Werde ich mir heute anschauen, danke!

Ich habe heute Abend auch noch etwas Zeit, wir können später unsere Notizen vergleichen.

Hallo, irgendwelche Fortschritte zu diesem Thema in der letzten Woche? Es kommt immer noch vor.

Für den Winkelmesser-Debugger/Explorer haben wir uns entschieden, ihn in Knoten 8 nicht zu unterstützen.

1. Winkelmesser-Debugger/Explorer, der hauptsächlich zum Debuggen von Tests im Kontrollfluss entwickelt wurde; aber Kontrollfluss ist etwas, das wir nicht fördern (insbesondere haben wir natives async/await in Knoten 8) und wird irgendwann veraltet sein.
2. Nach unserer Untersuchung stellten wir fest, dass es möglicherweise viel Aufwand erfordert, das Problem zu beheben, und dass sich dies gemäß Grund 1 nicht lohnt.
3. Wir arbeiten daran, neue Debugging-Dokumente für Node 8 bereitzustellen, indem wir das native Async/Await- und Chrome-Inspektor-Tool verwenden, das eine bessere Erfahrung als der ursprüngliche Debugger bietet.
4. @phenomnomnominal Wenn Sie

Hast du dafür eine ETA? Wir kauen an dem Gebiss dafür, wo ich arbeite. Wir versuchen, einigen Leuten das e2e-Testen beizubringen, und wir haben keine Möglichkeit, in den Debug-Modus zu wechseln und Code tatsächlich in dem Kontext auszuführen, in dem der Fehler auftritt. Wenn es eine Möglichkeit gibt, dies außerhalb dieses Vorgangs zu tun, lassen Sie es mich bitte wissen.

@KellyR-STCU
Hi,
Für Knotenversion < 8 können Sie den ursprünglichen Debugging-Prozess/-Tools verwenden.
Für Knotenversion >=8 können Sie dem neuen Debugging-Prozess folgen, der Node.js natives async/await verwendet, um asynchrone Aufrufe zu verarbeiten (damit wir uns nicht auf den Kontrollfluss und den alten Debugger verlassen müssen) und Chrome Inspector( oder ein anderer Knoten-Debugger) zu debuggen

Wir haben einige Dokumente, die beschreiben, wie man mit nativem async/await und Chrome Inspector debuggt
Debuggen mit deaktiviertem Kontrollfluss
wie man async/await verwendet

Ich hoffe es hilft

@qiyigg was ist mit elementExplorer?

@monkpit wird aus dem gleichen Grund in Node 8 nicht funktionieren. Wir haben keinen vollständigen Ersatz dafür, aber Sie können das Chrome-Entwicklungstool während des Debuggens öffnen und verwenden, es wird nicht mit dem Winkelmesser-Debugging kollidieren, wie wir es zuvor erlebt haben.

@qiyigg ok, da die elementExplorer-Funktion im Mittelpunkt des Problems stand, werde ich sie offen lassen.

Die Lösung ist auch ein kleines Problem, da vorhandene Tests neu geschrieben werden müssen, weil "Sie keine Mischung aus Async/Await und dem Kontrollfluss verwenden können". Es wäre schön, wenn Sie angeben könnten, welcher Ansatz pro Test verwendet werden soll, damit für den Wechsel nicht alle vorhandenen Tests aktualisiert werden müssen.

@uriah-ascend
Ja, ich muss zugeben, dass es keine perfekte Lösung ist. Aber wie ich oben erwähnt habe, wird der Kontrollfluss irgendwann entfernt . Unsere Tests in async/await umzuwandeln ist etwas, das wir schrittweise tun sollten, und es bietet uns eine bessere Debugging-Erfahrung.
Ich denke, Sie könnten eine separate Testkonfiguration für neue Tests erstellen und diese dann schrittweise konvertieren.

@qiyigg gibt es eine Anleitung oder Dokumentation zum Konvertieren in Async/Await?

Ziemlich gute Informationen in diesen beiden Links mit dem Titel Debugging mit deaktiviertem Kontrollfluss und
wie man async/await verwendet

Der zweite ist wahrscheinlich eher eine schrittweise Umstellung.

Nachdem ein Problem mit browser.pause() auf Knoten 8 aufgetreten ist.

Ich bin dem deaktivierten Kontrollfluss gefolgt.

Anstatt node --inspect-brk bin/protractor <config_file> auszuführen und im Browser zu debuggen, verwende ich node inspect $(which protractor) <config_file> gefolgt von debug> cont im Terminal.

Jetzt habe ich browser.pause() Äquivalent.

dh verwenden Sie debugger anstelle von browser.pause()

Nur um zu überprüfen: Wir haben eine große Winkelmesser-Codebasis, die nicht auf einmal in async/await konvertiert werden kann. Eine gute Möglichkeit, dies zu tun, besteht darin, zuerst alle "asynchronen" Winkelmesseraktionen mit der Verkettung von Versprechen zu konvertieren, oder? Auf diese Weise sollten die Dinge funktionieren, unabhängig davon, ob die Ablaufsteuerung aktiviert ist oder nicht.
Vielen Dank !

Die Verkettung von Versprechen funktioniert, unabhängig davon, ob der Kontrollfluss aktiviert ist oder nicht, aber es ist manchmal etwas chaotisch und Sie möchten es vielleicht eines Tages wieder auf asynchron / warten ändern?
Mein Vorschlag ist also, vorerst zwei separate Konfigurationen zu haben, den neuen Test / konvertierten Test in die neue Konfiguration zu stecken, die control_flow deaktiviert und die alte nach und nach loszuwerden

Das Problem ist, dass wir viele Funktionen zwischen Tests teilen. Wenn wir diese Funktionen also zu async-await migrieren, werden alle Tests abgebrochen, die sie verwenden und die nicht zu async-await migriert wurden (Hinweis: VIEL). Und wenn wir zwei Versionen derselben Funktion behalten, riskieren wir, dass sie divergieren.
Es scheint mir also, dass wir entweder alles verschieben, um Verkettung als Zwischenschritt zu versprechen, bevor wir zu async/await wechseln, oder wir richten babel ein, um unsere Testcodebasis zu transpilieren (mit etwas wie dem: https://stackoverflow.com/questions/ 28708975/transpile-async-await-proposal-with-babel-js ?), sodass wir async/await schreiben und in etwas transpilieren lassen können, das entweder mit Kontrollfluss oder ohne ausgeführt werden kann.
Weiß jemand ob das schon mal gemacht wurde?
Auf jeden Fall scheint es eine gute Idee zu sein, Migrationspfade für große Codebasen in der Readme anzugeben...

Macht Sinn, eigentlich denken wir vor kurzem darüber nach.
Ich habe mit einem internen Team gesprochen, das eine große Codebasis auf async/await migriert hat.
Sie fanden heraus, dass es subtile Fehler und Race-Conditions einführte, wenn sie allgemeine Utils in Promise-Chain änderten, und sie haben dies bereits aufgegeben.
Sie haben einige gängige Utils kopiert und in async/await übersetzt. Ich weiß nicht, ob es die beste Lösung ist, aber wie Sie erwähnt haben, birgt es ein gewisses Risiko
Wir arbeiten auch daran, ein Migrationstool zu schreiben, um es einfacher zu machen, aber die Tools funktionieren möglicherweise nicht extern.

Wie auch immer, wir arbeiten vor kurzem an einem Migrationsplan und sollten in naher Zukunft einige Migrationstipps geben.

Vielen Dank für Ihre Antwort, es ist gut zu wissen, dass es sich um ein Problem handelt
untersucht werden!
Ich denke, es wäre eine gute Idee, ein bestimmtes Thema für die Vorgehensweise zu erstellen
große Codebasen migrieren, damit die Leute sehen, dass daran gearbeitet wird.

Le 16 Jan. 2018 19:58, "qiyi" [email protected] a écrit :

Macht Sinn, eigentlich denken wir vor kurzem darüber nach.
Ich habe mit einem internen Team gesprochen, das eine große Codebasis zu migriert hat
asynchron/warten.
Sie fanden heraus, dass es subtile Fehler und Rennbedingungen einführt, wenn sie
gängige Utils in Promise Chain geändert und das haben sie bereits aufgegeben.
Sie haben einige gängige Utils kopiert und in async/await übersetzt. ich
weiß nicht, ob es die beste lösung ist, aber wie gesagt, es wird
haben ein abweichendes Risiko
Wir arbeiten auch daran, ein Migrationstool zu schreiben, um es einfacher zu machen, aber
die Tools funktionieren möglicherweise nicht extern.

Wie auch immer, wir arbeiten vor kurzem an einem Migrationsplan und sollten einige geben
Migrationsberatung in naher Zukunft.

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/angular/protractor/issues/4307#issuecomment-358068096 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AHHOgiLEdFS-xZVcOKmO1EB-CID53cryks5tLPFagaJpZM4NtM1n
.

Hallo Leute! Gibt es eine Problemumgehung?

protractor - 5.2.2
nodejs - 9.3

protractor --elementExplorer
(node:72438) [DEP0022] DeprecationWarning: os.tmpDir() is deprecated. Use os.tmpdir() instead.
[19:15:43] I/local - Starting selenium standalone server...
[19:15:44] I/local - Selenium standalone server started at http://172.29.148.101:58279/wd/hub
[19:15:45] I/protractor -
[19:15:45] I/protractor - ------- Element Explorer -------
[19:15:45] I/protractor - Starting WebDriver debugger in a child process. Element Explorer is still beta, please report issues at github.com/angular/protractor
[19:15:45] I/protractor -
[19:15:45] I/protractor - Type <tab> to see a list of locator strategies.
[19:15:45] I/protractor - Use the `list` helper function to find elements by strategy:
[19:15:45] I/protractor -   e.g., list(by.binding('')) gets all bindings.
[19:15:45] I/protractor -
module.js:557
    throw err;
    ^

Error: Cannot find module '_debugger'
    at Function.Module._resolveFilename (module.js:555:15)
    at Function.Module._load (module.js:482:25)
    at Module.require (module.js:604:17)
    at require (internal/module.js:11:18)
    at Object.<anonymous> (/usr/local/lib/node_modules/protractor/built/debugger/debuggerCommons.js:1:82)
    at Module._compile (module.js:660:30)
    at Object.Module._extensions..js (module.js:671:10)
    at Module.load (module.js:573:32)
    at tryModuleLoad (module.js:513:12)
    at Function.Module._load (module.js:505:3)
[19:15:45] I/local - Shutting down selenium standalone server.
MB-219751:~ olekh$ 

Erleben Sie auch die Error: Cannot find module '_debugger' , OSX.

Diese Ausgabe ist seit fast einem Jahr geöffnet. Immer noch kein Fortschritt?

@ajklotz Ich kann bestätigen, dass es immer noch nur mit Node 7 funktioniert. Ich habe nvm verwendet , um zwischen Node-Versionen zu wechseln, um den Element-Explorer zu verwenden. Es ist ein Schmerz, aber es funktioniert!

@ajklotz @monkpit @mraible Wenn Sie mit Node 8 oder höher laufen können, empfehle ich Ihnen, Folgendes zu versuchen:

1. Sehen Sie sich dieses Video "Winkelmesser: Eine neue Hoffnung" https://youtu.be/6aPfHrSl0Qk?t=1051 an , speziell ab 17:31
2. Wechseln Sie zu Node 8 oder höher
3. Konvertieren Sie Ihre Tests zur Verwendung der ES2017 async/await-Schlüsselwörter: https://github.com/angular/protractor/blob/master/docs/async-await.md
4. Fügen Sie SELENIUM_PROMISE_MANAGER: false, zu Ihrer protractor.conf.js hinzu
5. Verwenden Sie die neue Funktion debugger und verwenden Sie den Chrome-Inspektor zum Debuggen: https://github.com/angular/protractor/blob/master/docs/debugging.md#disabled -control-flow

Ich habe dies mit meinen eigenen Winkelmesser-Tests getan und bestätige, dass es funktioniert.

@ajklotz @monkpit @mraible Hier ist ein Beispiel, in dem ich Winkelmesser-Tests konvertiert habe, um async/await zu verwenden: https://github.com/buildbot/buildbot/pull/4074/files

Vor allem, was ein Versprechen zurückgibt, kleben Sie ein await davor, wie zum Beispiel:

• .click()
• .browser.wait()
• .browser.get()
• .getText()

Wenn eine Funktion einen Aufruf von await , muss vor der Funktionssignatur async .

Wenn Sie eine Funktion mit async aufrufen, müssen Sie sie await aufrufen.

Es dauert eine Weile, aber wenn Sie es getan haben, funktioniert es.

@rodrigc Mein protractor --elementExplorer von der Befehlszeile aus nicht funktioniert, es sei denn, Sie verwenden Knoten 7.

FWIW, scheint ein Sprachfeature wie async/await sowieso irrelevant zu sein. Vielleicht ist ein Tausch als Notlösung sinnvoll, aber Protractor impliziert keine Abhängigkeit von diesem Stil.

@monkpit Ja, du hast vollkommen recht. Die Ursache Ihres Problems ist, dass in dieser Zeile: https://github.com/angular/protractor/blob/master/lib/debugger/debuggerCommons.js#L1 das Modul _debugger importiert wird, das ist auf node8 nicht verfügbar. Alles, was debuggerCommons.js wird daher auf node8 nicht funktionieren, einschließlich elementExplorer .

Wenn Sie also node8 oder höher verwenden und mit Winkelmesser debuggen möchten, verwenden Sie async/await und befolgen Sie die Schritte unter: https://github.com/angular/protractor/blob/master/docs/ debugging.md

Das alte Debugging-Zeug wird nicht funktionieren.

Entweder wird es nicht behoben (das ist in Ordnung, ich kann den Workaround verwenden) oder es wird aktualisiert, um Knoten 8+ zu verwenden (das ist auch in Ordnung). Aber ich würde mich über eine offizielle Antwort auf die eine oder andere Weise freuen.

@monkpit

Ich denke, die Antwort liegt in diesem Kommentar von @qiyigg.

Für den Winkelmesser-Debugger/Explorer haben wir uns entschieden, ihn in Knoten 8 nicht zu unterstützen...

Von dem, was ich von @qiyigg gehört

Ich schließe dieses Thema vorerst. Es steht noch zur Diskussion.

@qiyigg Ich habe angefangen, das neue debugger mit Chrome Inspector und node8 zu verwenden und es funktioniert gut.

Kann das Winkelmesser-Team damit beginnen, die Dokumentation für den alten Debugging-Code, der debuggerCommon.js als DEPRECATED zu markieren ? Ich stimme @monkpit zu, dass es jetzt etwas verwirrend ist, wo der Code nicht mit

Wenn Sie sich das Debugging-Dokument ansehen, haben wir bereits erwähnt, dass der Debugger auf Node 8 nicht funktioniert
https://github.com/angular/protractor/blob/master/docs/debugging.md#enabled -control-flow
"Hinweis: Winkelmesser-Debugger und Element-Explorer können nicht für Node.js 8+ verwendet werden"

Beachten Sie Folgendes: Nicht jeder verwendet Node 8+, wir können nicht sagen, dass der Debugger veraltet ist, und alle zwingen, async/await zu verwenden (obwohl wir dies in Google tun werden).

Anscheinend hat der Wechsel zu Node 8+ und async/await viele Vorteile und wir sollten irgendwann dazu wechseln, aber es ist keine leichte Aufgabe, da wir viel unseres bestehenden Codes ändern müssen. Wir arbeiten daran innerhalb von Google und versuchen, mehr Erfahrung mit Migration (sogar Migrationstools) zu sammeln und hoffen, dass es letztendlich auch Benutzern außerhalb von Google helfen kann.

Ich denke, was wir jetzt tun könnten, ist, diesen Fehler klarer zu machen, sagen wir, eine Ausnahme auszulösen: Element Explorer/Debugger wird für Node 8+ nicht unterstützt anstelle von "Fehler: Cannot find module '_debugger'", Ein PR wird sehr sein begrüßt.

@qiyigg Ich würde vorschlagen , dass die Warnung in Fettschrift und ALL CAPS zu machen. Auf dieser Seite ist es etwas schwer zu verstehen, da es viele Wörter gibt.

ich bin sehr zufrieden mit dem neuen Debugger, weil ich Intellij verwenden kann, um meine Tests durchzuführen. Dies ist viel besser als der Element Explorer (der mir eher gefallen hat), aber die Verwendung meiner IDE zum Debuggen von Tests ist ein großer Gewinn.

@qiyigg Ich arbeite in einer Firma, die große Produktionsdrucker herstellt. Da wir alle unsere UIs auf Angular umgestellt haben (hurra!) haben wir uns entschieden, Protractor für die UI E2E-Tests zu verwenden (auch hurra). Abgesehen von diesen E2E-Tests haben wir auch echte End-to-End-Tests, die auf einem tatsächlich laufenden System funktionieren. Alle Testfälle für dieses Testsystem sind im Microsft TFS-Testframework spezifiziert und wir verwenden eine DSL, um sie zu schreiben. Diese DSL lädt die Seitenobjekte, die wir für unsere Benutzeroberflächen geschrieben haben, über einen interaktiv gestarteten Winkelmesser (also den Element-Explorer) und ruft Methoden auf, um seine Tests auszuführen.

Soweit so gut, würde man sagen, wir haben Tausende dieser Tests und sie laufen wirklich "als Benutzer". Was ich aus dieser Unterhaltung mache, ist, dass der Element-Explorer mit dem neuen Knoten gelöscht wird (und der neue Knoten ist für das Upgrade von Angular obligatorisch). Das bedeutet auch, dass unsere gesamte Testbasis plötzlich nicht mehr funktioniert.

Ich erhalte die Änderung mit async / wait und wir werden unsere Seitenobjekte natürlich neu schreiben, um sie zu unterstützen, aber es gibt keine wirkliche Alternative zum Einfügen von Winkelmesserbefehlen aus der Ferne, oder? Ich werde immer "einen Test" bestehen müssen, der nur "Debugger" aufruft, und dann direkt mit Chrome kommunizieren, um einen Befehl auf meinen Seitenobjekten aufzurufen und dann zum nächsten "Debugger" -Aufruf zu laufen, den ich dann wahrscheinlich ausführen muss in einer while-Schleife.

Wurden Szenarien wie diese nicht unterstützt? Werden sie es nicht sein? Oder übersehe ich nur etwas ... Für mich ist das Debuggen von Fehlern in Ihren Tests/Codes völlig anders als das Anweisen von Testbefehlen aus der Ferne. Letzteres ist etwas, das der Element-Explorer verwendet hat, um es zu erleichtern :)

Um zumindest meine aktuelle Lösung zu teilen, habe ich diesen Test geschrieben, der der einzige Systemtest ist, den ich mit Winkelmesser durchführe (CompletableFuture ist offensichtlich eine Hilfsklasse):

jasmine.DEFAULT_TIMEOUT_INTERVAL = 3600000; // arbitrary large timeout
(global as any).systemTestsDone = new CompletablePromise<void>();

describe('TestHelper', () => {
  it('should provide a way to interactively run tests', async () => {
    await (global as any).systemTestsDone;
  });
});

node --inspect .\node_modules\protractor\bin\protractor .\systemTests\protractor.conf.js

Dieser Test läuft dann weiter, während ich meinen (C#) WS-Client verbinde, der als Brücke zwischen den Testspezifikationen und den Seitenobjekten fungiert. Diese Brücke weist dann den Browser an, die Seitenobjekte zu laden und die Tests werden ausgeführt.

Der letzte Befehl den ich an den Browser sende ist natürlich

global.systemTestsDone.complete()

damit der Test normal abgeschlossen wird. Ich finde das nicht wirklich schlimm, das einzig Merkwürdige ist, dass ich jetzt einen Test missbrauchen muss, um in einen interaktiven Modus zu gelangen. Wenn mehr Personen solche Funktionen vermissen, ist es möglicherweise eine gute Idee, sie wieder in den Winkelmesser aufzunehmen. Ich meine nicht ein komplettes Devtools-Protokoll, sondern die Option, den Winkelmesser laufen zu lassen, während Sie beispielsweise die Chrome-Konsole oder den Visual Studio-Code als "Element Explorer" verwenden.

füge @vikerman hinzu , der das Protractor-Zeug übernehmen wird.

@vikerman Soll ich aus den obigen Kommentaren eine Funktionsanfrage stellen?

Kurz gesagt, was ich im Winkelmesser gerne hätte (da --elementExplorer nicht mehr mit den neuesten node.js-Versionen funktioniert) ist ein Modus, der nur den Winkelmesser startet, Spezifikationsdateien ignoriert und einfach weiterläuft, bis ein manueller Methodenaufruf erfolgt (so etwas wie protractor.exit() ?). Wir könnten den Winkelmesser in diesem Modus mit node --inspect starten, einige Seitenobjekte laden und einen externen Test-Runner mit dem Debugger-Protokoll verbinden und die Tests interaktiv ausführen.

Das wäre wirklich gut, wenn das jemand behebt. Ich verwende derzeit nvm als Workaround.
Ich verwende nvm, um den Knoten 7.10.1 zu installieren und von dort aus den ElementExplorer zu starten.
etwas lahmer Workaround, aber es funktioniert für jetzt

Ich habe ein Downgrade auf Node v6 durchgeführt, damit dies funktioniert, und jetzt kann ich meine Angular 6-App nicht ausführen, da Node 6 in Angular 6+ nicht unterstützt wird. Es sieht so aus, als ob Angular jetzt auf Knoten >= 8.9.0 zielt.

Gibt es eine gute Lösung, die ich befolgen kann, um einen Winkelmesser REPL zu erhalten, ohne zwei Versionen von Knoten ausführen zu müssen?

Ich habe den gleichen Fehler in der Konsole. Ich befolge diese Anweisungen hier
https://github.com/angular/protractor/blob/master/docs/debugging.md#enabled -control-flow

aber es kommt immer noch der gleiche Fehler

Ist das also das Ende von browser.pause() / browser.debugger()? Anscheinend sollten wir uns von der Ablaufsteuerung entfernen und den Knoten-Debugger verwenden.
https://github.com/angular/protractor/blob/master/docs/debugging.md

Die Verwendung von NVM zum Wechseln zur Knotenversion 7.10.1 hat das Problem browser.pause() für mich behoben.

Ich verstehe, dass async/await der richtige Weg ist und die Verwendung von Webstorm zum Debuggen von Tests mit Breakpoints absolut nahtlos ist, aber das Fehlen von elementExplorer ist meiner Meinung nach die erweiterte Verwendung im Elementor- Paket, die eine wunderbare Möglichkeit war, Teile interaktiv zu testen des Codes on the fly (in der Omnibox), anstatt den gesamten Test von Grund auf neu auszuführen.
Mit dem angegebenen Debugging-Prozess für nodejs 8+ lösen die Befehle von der Konsole keine Versprechungen auf, während der Inspektor an einem Haltepunkt angehalten wird, was meiner Meinung nach nicht intuitiv ist, aber all dies hat einen subtilen Anstieg der Zeit für das Schreiben/ Debug-Tests und Verlust einer weit verbreiteten Funktion (nach Anzahl der Antworten in diesem Thread).
Gibt es Pläne, die alte elementExplorer-Funktion im Winkelmesser zu ersetzen?

@woppa684 Vorschlag funktioniert gut für mich. Danke @woppa684. Ich bin gerade zu Knoten 10+ gewechselt, der repl-await hat (damit Sie einfach in der Konsole warten können)

Alle meine Konfigurationsdateien als Referenz hinzugefügt, hoffentlich hilft es jemandem:

Spezielle interaktive Debug-Spezifikation - interactive.e2e.ts

import { LoginPage } from './src/pages/login.po';
import { AppPage } from './src/pages/app.po';
import { SwitchProfileSideSheet } from './src/side-sheets/switch-profile-side-sheet.po';
import { sel } from '../src/testing/get-component';

const login = new LoginPage();
const app = new AppPage();
const switchProfileSideSheet = new SwitchProfileSideSheet();

// add my own page objects to the global object so I can use them interactively.
global['sel'] = sel;
global['po'] = {
  login,
  app,
  switchProfileSideSheet,
};

(global as any).systemTestsDone = new Promise(function(_resolve, _reject) {
  global['finishInteractiveDebug'] = _resolve;
});

describe('TestHelper', () => {
  it('should provide a way to interactively run tests', async () => {
    await (global as any).systemTestsDone;
  });
});

Paket.json

    "e2e-interactive": "node --experimental-repl-await --inspect-brk ./node_modules/.bin/protractor ./e2e/protractor.interactive.conf",

protractor.interactive.conf.js

// Protractor configuration file, see link for more information
// https://github.com/angular/protractor/blob/master/lib/config.ts

// standard protractor config
const baseConfig = require('./protractor.conf');
const configCopy = Object.assign({}, baseConfig.config);

const oneDayInMilliSeconds = 1000 * 60 * 60 * 24;
// set timeout to a huge number
// so it's not an issue when we pause in the debugger
configCopy.allScriptsTimeout = oneDayInMilliSeconds;
configCopy.jasmineNodeOpts.defaultTimeoutInterval = oneDayInMilliSeconds;
// just load our interactive specs
configCopy.specs = ['./interactive.e2e.ts'];

console.log('interactive config', configCopy);
exports.config = configCopy;

Ich verwende browser.sleep(100000) anstelle von browser.pause()