What is the best practice for debugging during webpack build process? Any console.log in the entry script doesnt output to node console.
As of the current version of webpack (September 2019), if you do a build instead of launch a dev server, console.log will output to std out (i.e. the node console).
Just make sure you are doing a full build (i.e. "npm run build") instead of a dev server (i.e. "npm run dev").
The dev server disables console.logs during the compile process in many circumstances, and/or the way the progress bar updates, the console.log strings are overwritten so you never see them.
Related
I'm having issues with memory leaks coming from running my test suites with Jest where memory usage keeps growing with each suite.
After searching through the net, I've found that this could be related to a garbage-collector behaviour, and multiple Github threads suggest running this command:
node --expose-gc ./node_modules/jest/bin/jest.js --coverage --runInBand --logHeapUsage
The issue is that my project uses React (with CRA not ejected) and Typescript, so whenever I run this script it throws a Syntax error because of Typescript.
I've tried installing ts-jest library but it does not work. It may be related, but running the ts-jest setup init complains about already having a configuration due to CRA.
I've been searching and I have not found anything, since all related threads are about the known memory leaks Jest has, but none explain how to execute the node command with the expose-gc in a project with React and Typescript.
Is there any way I can expose the GC to the Jest script used by CRA so I can keep using the same configuration as until now?
Otherwise, how can I execute the node --expose-gc jest parsing my files so that it does not throw an error?
I'd also need to use the --inspect-brk to see where the leak comes from, so even if the --detect-leaks works, I still need to find a way to execute my Jest config from node command.
Thank you!
After reviewing the documentation from Jest, I've seen this section which suggests to run the debug configuration in VS Code calling react-scripts. After playing a little bit with it, this is the command that got it working:
node --inspect-brk node_modules/react-scripts/scripts/test.js --no-cache --env=jsdom --runInBand
As you can see, you have to call the test.js file inside react-scripts directly, and then you can send all the arguments you want to Jest, as you'd normally do when running tests directly from the terminal of your project.
If you execute this script:
node --inspect-brk node_modules/react-scripts/bin/react-scripts.js test --no-cache --env=jsdom --runInBand
You will be able to attach to the node debugger, but you won't be able to set debugger stops in your test files, as it will attach to the main process, which is react-scripts (and not the test script itself).
Hope this might help someone in a future!
I have an Angular Universal app.
I am able to run 'npm run start', which executes 'ng serve' and the live development server starts listening.
If instead I run 'node dist/server.js', it simply exits without any info or error messages.
check out the $.scripts.start field within the project's package.json file. That will tell you what command is being invoked through npm start, which might not necessarily be node dist/server.js. Default values for the start script are found here
Also, depending on what flavor of Javascript they are running, there might be a build step that you are missing.
I use mocha to run my unit tests, and often use npm test in order to run it. My package.json contains these script definitions:
"pretest": "NODE_ENV=test node migrate all",
"test": "DEBUG= NODE_ENV=test mocha --recursive",
If I run either one of these commands directly in my shell (i.e. not going through npm) they execute fine (790 tests takes about 2m to run, the migration script is done in under 1s). The processes also exit cleanly.
If, however, I run these via npm test, everything runs in exactly the same way but the process doesn't exit (I have to manually cancel it with ^c).
I can't work out how to debug exactly what is going on here in order to work out why the process isn't exiting.
It's worth noting that if I test a subdirectory (npm test ./test/queue) which does not interact at all with the database, then the process exits fine. These tests do, however, interact with an AMQP broker so there is some activity over sockets. This suggests to me that the database connection is causing the problem. I am using knex to connect to a postgres9.6 server. This also suggests that the pretest script is not the problem. If I try to run a suite of tests which do interact with the database, the process never exits (so presumably the open sockets are preventing it from doing so, but why this should only happen in the case of npm test rather than direct execution is beyond me).
Extra info:
node version: 8.7.0
mocha version: 4.0.1
npm version: 5.6.0
knex version: 0.14.0
I am using async/await in my codebase
I was mistaken in thinking this to be an npm problem. Rather, when I was running mocha in my shell it was using the globally installed mocha, which is of a different version to the locally installed one. Running with this version causes the same hanging issue.
This change in behaviour appears to be coming from this issue, which is described thus in the changelog:
By default, Mocha will no longer force the process to exit once all tests complete. This means any test code (or code under test) which would normally prevent node from exiting will do so when run in Mocha. Supply the --exit flag to revert to pre-v4.0.0 behavior (#ScottFreeCode, #boneskull)
I've been trying to use Nuclide/Atom to launch and debug a unit test that uses Babel and ES6+ code. The launch config looks like this:
Node runs the unit test as if I had run it from the command-line, and does not stop at my breakpoints. If I use the same invocation at the command-line with --inspect-brk I can debug correctly (with sourcemaps) from the chrome-devtools url in Chrome. Is there a way to make this work? I can't really "attach" since the unit tests are, and should be, a straight-shot script execution.
Nuclide currently does not support the new v8 Inspector protocol for debugging. You will need to use --debug flag to debug with Nuclide. Note, however, that the old debugger protocol has been removed from Node.js starting with Node.js 8.0.
PS. You can attach to a running Node.js process with Nuclide debugger just fine - just start your tests with node --debug --debug-brk ... and then attach the debugger from Nuclide. The test process will be stopped at first line, allowing you to resume execution at your own convenience.
I am using webstorm 10.0.2 and have used the bangular yeoman template to generate a project. I can run the gulp commands via the gulp window, and I can set a breakpoint in the gulpfile.js and it will hit it, but I can't seem to get it to hit a breakpoint in my server.js
It looks to me like the gulp file is launching another instance of node and thus when you do "debug" from webstorm you are just debugging the gulp.
I also tried with another project using yo hottowel but get the same thing - I am unable to debug the actual application through webstorm.
Can anybody tell me how to configure webstorm so that I can debug the actual server side node code but still use the gulp build tool?
I contacted JetBrains support back in May 2015 and their response was:
It seems this cannot be done quickly. In short, the problem is that serve-dev task starts new process (nodemon) that takes app.js
There is no workaround how to debug such spawned processes right now. We would really appreciate if you'll submit a feature request about it in our YouTrack: https://youtrack.jetbrains.com/issues/WEB
The only way you can try to avoid it - try to create a separate task that will run app.js directly without nodemon process and debug this task instead.
It seems the best option is to use https://www.npmjs.com/package/gulp-node-inspector