WebStorm debugging suddenly *stopped* working (?)

I have WebStorm set up to debug a React app using a Javascript Debug configuration.  It connects to a custom Chrome instance -- custom, so that I can retain my particular Chrome setup (Redux Dev Tools, etc) in the instance opened by the debugger. All was going well and then -- changing nothing -- it stopped working.

By "stopped working" I mean that when I click on the little debug icon in the toolbar the app starts up and loads in the custom Chrome instance (I quit Chrome between debug sessions, as instructed), and the little 'stop' square lights up.  But the debug icon is not lit up.  That is, it doesn't show it's debugging.  Neither does it stop on breakpoints (see screenshot) 

The weird thing is that when I click on the little red box to stop the process, then the little bug icon lights up with a green dot on the bottom (it's debugging) and a new tab opens up in the Chrome instance.  I need to click the red square again to stop everything

I tried restarting WS, as well as creating a new debug config (see screenshot) 

(I tried it both with 'ensure breakpoints' not checked, as I had it originally, as well as checked -- no difference)

The NPM script command is

`package.json` has this script


"start": "node scripts/start.js",

and the actual script is at the end of this post (it is a long script which I didn't write and don't understand).

It's frustrating, as it was working perfectly.  The only thing I did in the meantime was, I believe, kill an errant process on port 3002.  That's pretty much it.  I know it's not much to go on but I am dead in the water.

/scripts/start.js

'use strict';

// Do this as the first thing so that any code reading it knows the right env.
process.env.BABEL_ENV = 'development';
process.env.NODE_ENV = 'development';

// Makes the script crash on unhandled rejections instead of silently
// ignoring them. In the future, promise rejections that are not handled will
// terminate the Node.js process with a non-zero exit code.
process.on('unhandledRejection', err => {
throw err;
});

// Ensure environment variables are read.
require('../config/env');

const fs = require('fs');
const chalk = require('react-dev-utils/chalk');
const webpack = require('webpack');
const WebpackDevServer = require('webpack-dev-server');
const clearConsole = require('react-dev-utils/clearConsole');
const checkRequiredFiles = require('react-dev-utils/checkRequiredFiles');
const {
choosePort,
createCompiler,
prepareProxy,
prepareUrls
} = require('react-dev-utils/WebpackDevServerUtils');
const openBrowser = require('react-dev-utils/openBrowser');
const paths = require('../config/paths');
const configFactory = require('../config/webpack.config');
const createDevServerConfig = require('../config/webpackDevServer.config');

const useYarn = fs.existsSync(paths.yarnLockFile);
const isInteractive = process.stdout.isTTY;

// Warn and crash if required files are missing
if (!checkRequiredFiles([paths.appHtml, paths.appIndexJs])) {
process.exit(1);
}

// Tools like Cloud9 rely on this.
const DEFAULT_PORT = parseInt(process.env.PORT, 10) || 3002;
const HOST = process.env.HOST || '0.0.0.0';

if (process.env.HOST) {
console.log(
chalk.cyan(
`Attempting to bind to HOST environment variable: ${chalk.yellow(
chalk.bold(process.env.HOST)
)}`
)
);
console.log(
`If this was unintentional, check that you haven't mistakenly set it in your shell.`
);
console.log(
`Learn more here: ${chalk.yellow('https://bit.ly/CRA-advanced-config')}`
);
console.log();
}

// We require that you explicitly set browsers and do not fall back to
// browserslist defaults.
const { checkBrowsers } = require('react-dev-utils/browsersHelper');
checkBrowsers(paths.appPath, isInteractive)
.then(() => {
// We attempt to use the default port but if it is busy, we offer the user to
// run on a different port. `choosePort()` Promise resolves to the next free port.
return choosePort(HOST, DEFAULT_PORT);
})
.then(port => {
if (port == null) {
// We have not found a port.
return;
}
const config = configFactory('development');
const protocol = process.env.HTTPS === 'true' ? 'https' : 'http';
const appName = require(paths.appPackageJson).name;
const useTypeScript = fs.existsSync(paths.appTsConfig);
const urls = prepareUrls(protocol, HOST, port);
const devSocket = {
warnings: warnings =>
devServer.sockWrite(devServer.sockets, 'warnings', warnings),
errors: errors => devServer.sockWrite(devServer.sockets, 'errors', errors)
};
// Create a webpack compiler that is configured with custom messages.
const compiler = createCompiler({
appName,
config,
devSocket,
urls,
useYarn,
useTypeScript,
webpack
});
// Load proxy config
const proxySetting = require(paths.appPackageJson).proxy;
const proxyConfig = prepareProxy(proxySetting, paths.appPublic);
// Serve webpack assets generated by the compiler over a web server.
const serverConfig = createDevServerConfig(
proxyConfig,
urls.lanUrlForConfig
);
const devServer = new WebpackDevServer(compiler, serverConfig);
// Launch WebpackDevServer.
devServer.listen(port, HOST, err => {
if (err) {
return console.log(err);
}
if (isInteractive) {
clearConsole();
}

// We used to support resolving modules according to `NODE_PATH`.
// This now has been deprecated in favor of jsconfig/tsconfig.json
// This lets you use absolute paths in imports inside large monorepos:
if (process.env.NODE_PATH) {
console.log(
chalk.yellow(
'Setting NODE_PATH to resolve modules absolutely has been deprecated in favor of setting baseUrl in jsconfig.json (or tsconfig.json if you are using TypeScript) and will be removed in a future major release of create-react-app.'
)
);
console.log();
}

console.log(chalk.cyan('Starting the development server...\n'));
openBrowser(urls.localUrlForBrowser);
});

['SIGINT', 'SIGTERM'].forEach(function(sig) {
process.on(sig, function() {
devServer.close();
process.exit();
});
});
})
.catch(err => {
if (err && err.message) {
console.log(err.message);
}
process.exit(1);
});

 

 

 

WebStorm 2019.3.2
Build #WS-193.6015.40, built on January 21, 2020
Runtime version: 11.0.5+10-b520.30 x86_64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
macOS 10.14.5
GC: ParNew, ConcurrentMarkSweep
Memory: 3987M
Cores: 16
Registry: ide.balloon.shadow.size=0
Non-Bundled Plugins: aws.toolkit, com.chrisrm.idea.MaterialThemeUI, izhangzhihao.rainbow.brackets, ru.adelf.idea.dotenv

12 comments
Comment actions Permalink

Please remove your NPM script from the Before launch section of you run configuration: a process added to Before launch has to return an exit code, the main process is waiting for its exit code to start and thus doesn't start until the first process terminates (that's why the debug session starts once you stop the npm script by pressing the red box). This is the way Before launch is designed - it's supposed to be used to run some sort of pre-processing before running the main process. But node scripts/start.js doesn't exit, it starts the server your application is hosted on, and it has to be running to make your application work. That's why adding your npm script to Before launch is a bad idea, you have to start it separately or use the Compound configuration to start both npm script and Javascript Debug run configuration concurrently

0
Comment actions Permalink

Thanks!  I did that and it works great.  But following the instructions here -- https://www.jetbrains.com/help/webstorm/run-debug-configuration-compound-run-configuration.html -- it would seem if I want to have the two configurations execute sequentially (first the node app starts, using a NodeJS debug config, and then the browser debug attaches to that), then I should use a JavasScript debug config and have the NodeJS config as a 'before' task?  That is, do it that way, instead of having the two in the same Compound config.  (see screenshot -- the NodeJS config just starts the 'start' script with Node).  The Compound way works, but it takes perhaps 10-15 seconds to load, so I'm wondering if that's because it's not sequential.


0
Comment actions Permalink

>it would seem if I want to have the two configurations execute sequentially (first the node app starts, using a NodeJS debug config, and then the browser debug attaches to that)

You need building the application and starting the server _before_ attaching a debugger to web page, so it's indeed a sequence. But still both processes have to be run concurrently - you can't open your page in browser if the server it's hosted on is not running, can't you? If you stop your server, all you would see in browser is 404 error.

Forget about the IDE, just think about the process you normally use to start your web application: you start your web server, then run the browser and open your app URL in it. Are these processes concurrent or sequential?

0
Comment actions Permalink

Thanks.

Forget about the IDE, just think about the process you normally use to start your web application: you start your web server, then run the browser and open your app URL in it. Are these processes concurrent or sequential?

To me it's sequential: boot the app, then point the browser to the endpoint.  You can't open an endpoint until the app is running, as you correctly point out.  Which is why I thought -- following the instructions I linked to -- that the correct way would be to attach the NodeJS config as a 'before' step to the JSDebug config.  However you specifically mentioned using a Compound debug config -- which, in the instructions above, would be concurrent.  Hence my confusion.

0
Comment actions Permalink

>To me it's sequential: boot the app, then point the browser to the endpoint. You can't open an endpoint until the app is running, as you correctly point out. 

The one has to be started after the other, but still concurrently. And, as I have mentioned above, Before launch can't be used for running processes concurrently.

0
Comment actions Permalink

OK, thanks, I won't fix what isn't broken.  Works fine, thanks to your help!

 

0
Comment actions Permalink

On a related note -- I also have a NextJS/React app (I'm "translating" the app mentioned above to a NextJS app) for which I've set up a Compound debug config, as above.  For the NodeJS part I simply have it execute the package script 'dev' (for "yarn dev").  

I press the debug 'bug' icon and the app starts 

but since the green dot doesn't appear on the debugger, I'm not sure it's connecting --- the breakpoints inside a Redux  reducer don't change from red, and although the lines at which the debugger should stop are executed, the breakpoints aren't hit.  (However this time if I start to edit the file, then the breakpoints are hit).  Perhaps it's because this is a NextJS application and WS isn't finding the source files where it expects to find them?  (If so, I'd appreciate any advice on a way forward)


(see images)

The debug config is similar to before

and in this case there's no funky 'start' script, just the NextJS 'dev' script

Any help much appreciated!

0
Comment actions Permalink

Tried next.js examples - breakpoints in reducers work as expected when using the JavaScript Debug run configurations like yours... Sourcemaps are not accurate, so it may pause on wrong lines, but it works in general.

When using Next.js, it's not always evident if the code is executed on a client or server side though... Did you try running the dev configuration in debugger?

BTW, does enabling 'ensure breakpoints' make any difference?

0
Comment actions Permalink

Thanks! -- when you say 'tried next.js examples', do you mean those from the NextJS site?

Running just the dev configuration didn't seem to do much -- since it's a NodeJS configuration, it didn't open the browser, so I opened an instance of Chrome myself and loaded the endpoint.  No stopping on breakpoints.

However, when I started the server separately (running yarn dev in the terminal), and then ran the JSDebug config from within WebStorm, then the WS debugger stopped on newly placed breakpoints.  So I deleted and replaced the breakpoints in my reducers and it worked!

So, it seems that's the right way to go.  It feels a bit precarious -- would there be any explanation as to why doing it the way I did it, and replacing the breakpoints, worked, so I'll know in the future exactly what I'm doing (and what I did to get it to work). 

0
Comment actions Permalink

>when you say 'tried next.js examples', do you mean those from the NextJS site?

yes, exactly

>Running just the dev configuration didn't seem to do much -- since it's a NodeJS configuration, it didn't open the browser, so I opened an instance of Chrome myself and loaded the endpoint.

Running the dev configuration is not supposed to debug the client-side code, and opening Chrome instance doesn't allow debugging the code that is run in browser, you need using JavaScript Debug configuration to start Chrome and attach the debugger to your page. So the right sequence of actions is running your dev configuration (to start the server, etc.) and then starting the JavaScript Debug configuration in debugger. If you need to debug the server-side code as well, debug your dev configuration instead of running it.

0
Comment actions Permalink

none of this stuff is making any since to me.  Debug has stopped working after update. No button to start the app i.e. browser with http://localhost:4200

Not sure what to do. Would like it to start working again.

-2
Comment actions Permalink

>No button to start the app i.e. browser with http://localhost:4200

Not sure what buttons you are talking about... Is it about run configurations? They are stored with project and shouldn't normally be affected by IDE updates; anyway, you can always create them manually in Run > Edit Configurations...

0

Please sign in to leave a comment.