protractor: Element explorer doesn't work on Node 8

Bug report

  • Node Version: 8.0.0
  • Protractor Version: 5.1.2
  • Angular Version: n/a
  • Browser(s): Chrome / chromedriver 2.29.0
  • Operating System and Version Mac Sierra 10.12.5
  • Your protractor configuration file n/a

After installing node v8.0.0 and npm v5.0.0, reinstalling protractor globally and running webdriver-manager update, I cannot run protractor --elementExplorer because I receive the following error:

protractor --elementExplorer
(node:76684) [DEP0022] DeprecationWarning: os.tmpDir() is deprecated. Use os.tmpdir() instead.
[11:04:10] I/hosted - Using the selenium server at http://localhost:4444/wd/hub
[11:04:11] I/protractor -
[11:04:11] I/protractor - ------- Element Explorer -------
[11:04:11] I/protractor - Starting WebDriver debugger in a child process. Element Explorer is still beta, please report issues at github.com/angular/protractor
[11:04:11] I/protractor -
[11:04:11] I/protractor - Type <tab> to see a list of locator strategies.
[11:04:11] I/protractor - Use the `list` helper function to find elements by strategy:
[11:04:11] I/protractor -   e.g., list(by.binding('')) gets all bindings.
[11:04:11] I/protractor -
module.js:487
    throw err;
    ^

Error: Cannot find module '_debugger'
    at Function.Module._resolveFilename (module.js:485:15)
    at Function.Module._load (module.js:437:25)
    at Module.require (module.js:513: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:569:30)
    at Object.Module._extensions..js (module.js:580:10)
    at Module.load (module.js:503:32)
    at tryModuleLoad (module.js:466:12)
    at Function.Module._load (module.js:458:3)

If I revert back to node 7.10.0 I don’t get this error.

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Reactions: 67
  • Comments: 65 (27 by maintainers)

Most upvoted comments

Are there plans from the team to get this working again with either the inspect API or something other approach?

Could we please know what are the plans for Node 8 support? 😃

Any updates on this?

@KellyR-STCU Hi, For node version < 8, you can use the original debugging process/tools. For node version >=8, you can follow the new debugging process, which uses Node.js native async/await to handle asynchronous call(so that we don’t need rely on control flow and old debugger), and use chrome inspector(or any other node debugger) to debug

We have some documents to describe how to debug with native async/await and chrome inspector debugging with control flow disabled how to use async/await

Hope it helps

With Node v8 set to enter LTS in October, maybe we could get an update?

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

For protractor debugger/explorer, we decided not to support it in node 8.

  1. Protractor debugger/explorer mainly designed to debug test in control flow; but control flow is something we don’t encourage(Especially we have native async/await in node 8) and will be eventually deprecated.
  2. After investigating, we found it might need much effort to fix it and not worth doing that according to reason 1.
  3. We are working on providing new debugging documents for node 8 using native async/await and chrome inspector tool, which will give better experience than original debugger.
  4. @phenomnomnominal If you have some breakthrough about this, we’d like to review it. Thanks for your effort.

@ajklotz @monkpit @mraible If you are able to run with Node 8 or higher, I recommend that you try to do the following:

  1. Watch this video “Protractor: A New Hope” https://youtu.be/6aPfHrSl0Qk?t=1051 , specifically starting around 17:31
  2. Switch to using Node 8 or higher
  3. Convert your tests to use the ES2017 async/await keywords: https://github.com/angular/protractor/blob/master/docs/async-await.md
  4. Add SELENIUM_PROMISE_MANAGER: false, to your protractor.conf.js
  5. Use the new debugger function and use chrome inspector to debug: https://github.com/angular/protractor/blob/master/docs/debugging.md#disabled-control-flow

I have done this with my own Protractor tests and confirm that it works.

Also experiencing the Error: Cannot find module '_debugger', OSX.

After having issue with browser.pause() on Node 8.

I followed Disabled Control Flow.

Instead of running node --inspect-brk bin/protractor <config_file> and do debugging in the browser, I use node inspect $(which protractor) <config_file> followed by debug> cont in the terminal.

Now I have browser.pause() equivalent.

i.e. use debugger in place of browser.pause()

I use browser.sleep(100000) instead of browser.pause()

If you take a look at the debugging document, we have already mentioned the debugger won’t work on Node 8 https://github.com/angular/protractor/blob/master/docs/debugging.md#enabled-control-flow “Note: Protractor debugger and element explorer cannot be used for Node.js 8+”

One thing to keep in mind is: not everyone is using Node 8+, we cannot say debugger is deprecated and enforce everyone to use async/await (Although we will do so inside google).

Apparently, moving to Node 8+ and async/await have many benefits and we should move to it eventually, but it is not an easy job since we have to change lots of our existing code. We are working on this inside google and try to accumulate more experience about migration (even migration tools)and hope it could also help users outside google eventually.

I think what we could do now is to make this error more clear, say, throw an exception: element explorer/debugger is not supported for Node 8+ instead of “Error: Cannot find module ‘_debugger’”, A PR will be very welcomed.

@qiyigg I have started using the new debugger with chrome inspector, and node8 and it works well.

Can the protractor team start marking the documentation for the old debugging code which uses debuggerCommon.js as DEPRECATED? I agree with @monkpit that things are a bit confusing now where the code does not work with node8, but it is not marked as deprecated. Ultimately this old debugging code should just be deleted if it is never going to get fixed with node8.

Only what I outlined above. I was planning on having a crack at it this evening.

I’ll try to dig into this in the next few days but a PR to fix this would be very welcome!

I’ve started having a look into this. Here are a bunch of guesses about how updating this might work:

As far as I can tell, the changes need to happen in debuggerCommons.js

Rather than require('_debugger'); it needs to use require('inspector'); (docs here). You can then open the inspector, create a session, connect to it, and then use session.post and the Chrome DevTools Protocol to send the messages to add the breakpoints.

I’ll have a crack at a PR when I get some time.

@qiyigg I would suggest to make that warning in bold and ALL CAPS. It is a bit hard to catch on that page, because there are a lot of words.

@rodrigc My tests area already using async/await, the point of this issue is that from the command line, protractor --elementExplorer doesn’t work unless you use node 7.

This issue has been open for almost a year. Still no progress?

I don’t think we are currently testing against node 8 so it makes sense that this may be broken. Thanks for bringing this up!

@woppa684 Suggestion is working nicely for me. Thanks @woppa684. I just moved to node 10+ which has repl-await (so you can just await in the console)

Added all my config files for reference, hopefully it helps someone:

Special interactive debug spec - 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;
  });
});

package.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;

I understand that async/await is the way forward, and using Webstorm to debug tests with breakpoints is absolutely seamless, but where I feel the absence of elementExplorer is its extended usage in the elementor package, which was a delightful way to interactively test out parts of code on the fly (in the omnibox) instead of running the entire test from scratch. With the given debugging process for nodejs 8+, the commands from the console do not resolve promises while the inspector is paused at a breakpoint, which I realise is counter-intuitive, but all this has meant a subtle increase in time spent on writing/debugging tests, and loss of a widely used feature (going by number of responses on this thread). Are there any plans to have a substitute for the old elementExplorer feature in protractor?

@ajklotz I can confirm it still only works with Node 7. I’ve been using nvm to switch between Node versions in order to use element explorer. It’s a pain, but it works!

Pretty good info in those two links he provided titled debugging with control flow disabled and how to use async/await

@phenomnomnominal Hi, any updates so far?

@phenomnomnominal that’s great, thanks a lot!

_debugger and the legacy CLI debugger were removed in Node 8: https://github.com/nodejs/node/commit/90476ac6ee

Using NVM to switch to node version 7.10.1 fixed the browser.pause() issue for me.

To at least share what my current solution is, I have written this test, which is the only system test I run with protractor (CompletableFuture is a helper class obviously):

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

This test then keeps running while I connect my (C#) WS client that acts as a bridge between the test specs, and the page objects. This bridge then instructs the browser to load the page objects and the tests start executing.

The last command I send to the browser is of course

global.systemTestsDone.complete()

so that the test completes normally. I don’t think this is really awful, the only strange thing is that I now have to abuse a test to get into an interactive mode. If more people are missing functionality like this it might be a good idea to include it in protractor again. I don’t mean an entire devtools protocol but the option to leave protractor running while you, for example, use the console of chrome or visual studio code as “element explorer”.

The solution is also a bit of a problem since it requires rewriting existing tests because “you cannot use a mix of async/await and the control flow”. It would be nice if you could specify which approach to take per test so that switching didn’t require updating all existing tests.

@qiyigg what about elementExplorer?

I will look into it today, thanks!

ok, thanks a lot. I am supposed to have some time after Monday, maybe I can also look into it after that.

I started having a go, but I was having issues with Selenium when trying to run the tests (any tips?). I’m going to have some more time Tuesday night. The new API is quite different, but I don’t foresee any real issues.