Grunt "aborted due to warnings" when too much output is generated - node.js

I work on a NodeJS project and I use grunt as task manager. In particular, I use grunt to run unit test and generate coverage reports.
The program under test has a configurable feature that allows to generate more or less output in the log (the typical ERROR/WARN/DEBUG selector). I have observed that if I run unit test with grunt with maximum logging verbosity (DEBUG) grunt coverage ends with:
Aborted due to warnings.
However, same grunt command with a less verbose log level (i.e. without touching a single line of code expect the log level configuration) works without problem and I get:
Done, without errors.
Has grunt some kind of "output limit" which when overpassed causes an abort situation? Can that limit be removed or configured anyway?
I'm using istanbul for code coverage. Version information follows (in the case they are useful):
$ node --version
v6.12.3
$ npm --version
3.10.10
$ grunt --version
grunt-cli v1.2.0
grunt v0.4.5
$ cat node_modules/istanbul/package.json | grep version
"version": "0.1.46"
(I'm new to grunt so sorry if I'm asking a silly question :)

Related

`npm test` never exits

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)

atom + mocha on windows = spawn mocha ENOENT

My goal is to run mocha unit tests by Atom, which is installed on Windows and also my src code resides. this should work independently from my Meteor App which is running on a different (Linux) machine.
Basically my setup is like this:
I have my repo and sourcecode:
c:\Users\Me\repos\meteor
My tests are inside:
c:\Users\Me\repos\meteor\tests
I have Node:
c:\Program Files\nodejs
installed with "npm i -g mocha --save-dev"
And i try to use this package https://github.com/Tabcorp/atom-mocha-test-runner but i can switch to another package if necessary.
What I've tried so far:
I edited my settings for the atom-mocha-test-runner:
Mocha command: C:\Program Files\nodejs\node_modules\mocha\.bin\mocha
Mocha command: C:\Program Files\nodejs\npm mocha
But each time i try to run my test via dropdown menu (Run Mocha Test), i get this error:
Mocha Test Results:
Node binary: C:\Program Files\nodejs\node.exe
Root folder: C:\Source\Repos
Mocha command: undefined
Path to mocha: mocha
Debug-Mode: false
Test file: tests\unit\first.js
Selected test: should return url
Failed to run Mocha
spawn mocha ENOENT
Anyone know what i miss or do wrong?
Still having no idea about why the package isn't working, I'm going to give a cop-out answer. If we figure out how to make it work, you can accept that answer instead. process-palette gives you the ability to run highly specific command-line instructions from Atom commands. Here's an example of a command that runs mocha in the project path for the current file with the same hotkey and also conveniently organized into its own menu item:
The disadvantage of this approach is that you have to know how to use the external program yourself. Packages like mocha-test-runner are designed to remove that need from the user, but as we can see here, sometimes the package doesn't know what it needs to be doing. The disadvantage is mitigated by the fact that you only have to learn the command for long enough to set up the configuration to run it, and from that point on it's very easy.
Advantages versus other packages include the ability to precisely control what's going on. Say you have multiple top-level folders in the current project, and they have different test suites. A package like mocha-test-runner can get the path from the active file, or from the project. If the developer chose to grab the project path, then you're going to have trouble running individual test suites. With the configuration I've shared, the command will always be run in the absolute path of the current file's project folder, so the tests will be run for whichever file you're working on at the time.

adding npm module to Tabris results in a failed build with cordova

Being rather new to mobile app development i'm looking at Apache Cordova paired with Tabris.
Tabris requires a particular installation procedure, this creates a ./node_modules sub-folder under the regular ./www folder of a typical cordova project. Build cordova here is not a problem.
After adding 'npm install pouchdb' to ./www/node_modules now the cordova build fails again and again. I don't see what else changed but the addition of pouchdb. Strangely while pouchdb is reported to be just 46KB after installation many more modules were added and it now weighs in at 55MB. I suspect the many extra modules pose an issue.
I suspect i may need to tweak gradle but i'm most clueless where to start.
please advise
--- below the output indicating build failure
.... many lines of output preced
:processDebugManifest
:processDebugResources FAILED
FAILURE: Build failed with an exception.
What went wrong:
Execution failed for task ':processDebugResources'.
com.android.ide.common.process.ProcessException: org.gradle.process.internal.ExecException: Process 'command '/opt/android-sdk-update-manager/build-tools/24.0.2/aapt'' finished with non-zero exit value 1
<<< this is supposedly output from gradle >>>
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
Total time: 13.708 secs
Error: Error code 1 for command: /usr/sources/mobile/.../platforms/android/gradlew with args: cdvBuildDebug,-b,/usr/sources/mobile/.../platforms/android/build.gradle,-Dorg.gradle.daemon=true,-Pandroid.useDeprecatedNdk=true
... replace path for anonymisation
<<< is my own inserted line >>>
First off: are you using Tabris or Tabris.js? The former is a Java framework and is not compatible with Cordova. The latter is, but if you're trying to use Tabris.js as a slave to Cordova (i.e. using the Cordova build command) that's not going to work. Instead I suggest you convert your project structure Tabris.js's style and then run the build there. If you still encounter errors when after converting your structure and building with Tabris.js, post the full build log in the Tabris.js issue tracker.

Grunt assemble - strange 'module not found' issue

I'm adapting an existing project to use Grunt, Assemble and other workflow tools. I have the workflow working on one machine, but when I try to run the Gruntfile on a different system I get an error:
[/home/ian/workspace/myproject] (master)
ian#ian-desktop $ grunt assemble
Running "assemble:pages" (assemble) task
Warning: Cannot find module '/home/ian/workspace/myproject/node_modules/
grunt-assemble/node_modules/assemble/node_modules/handlebars-helpers/
lib/helpers/home/ian/workspace/myproject/node_modules/grunt-assemble/
node_modules/assemble/node_modules/handlebars-helpers/lib/helpers/code.js'
Use --force to continue.
Aborted due to warnings.
The path that Grunt is trying to load is completely messed up (note the re-occurrence of the cwd about halfway through), but the filename it's looking for - code.js - is installed locally (by npm -i):
[/home/ian/workspace/myproject] (master)
ian#ian-desktop $ find . -name code.js
./node_modules/grunt-assemble/node_modules/assemble/node_modules/
handlebars-helpers/node_modules/remarkable/lib/rules_block/code.js
./node_modules/grunt-assemble/node_modules/assemble/node_modules/
handlebars-helpers/test/code.js
./node_modules/grunt-assemble/node_modules/assemble/node_modules/
handlebars-helpers/lib/helpers/code.js
./node_modules/grunt-mocha/node_modules/mocha/node_modules/jade/
lib/nodes/code.js
Both the systems I'm working on are Ubuntu 14.10, so shouldn't differ in any material way. Node -v gives v0.10.33, npm -v gives 2.1.5. I've tried:
checking out a fresh copy of the entire project from git
clearing all Bash environment vars before running Grunt
I'm having a hard time figuring out what's at the root of the different behaviour of the same code on two similar machines. Other tasks in my Gruntfile seem to be working fine, it's just the assemble task that's broken. Suggestions of where to look, or debug techniques to try, would be very welcome!

Running jasmine tests in Webstorm stops in trace with exit code 0

I run jasmine tests in my node.js application via grunt. I've added grunt test to Webstorm's run configurations.
In "Run/Debug Configurations" the "Grunt Test" has following properties specified: node interpreter (node.exe in Program Files), working directory (project location), JavaScript file (grunt binary), and application parameters (test - grunt task name).
The configuration works correctly but stops without printing full jasmine output. Sometimes before printing any output, most often after some part of jasmine log, but before test summary or error details. Always the last line of output is
Process finished with exit code 0
When I take the Webstorm command and run it manually in console it works fine and always prints full output:
"C:\Program Files\nodejs\node.exe" C:\...\node_modules\grunt-cli\bin\grunt test
My tests includes asynchronous cases, so it takes about 20 seconds to run them all.
I noticed that each attempt to run tests via Webstorm prints a bit longer output. First attempt ends without any but after ten further I got full output with test summary.
Known issue, please see http://youtrack.jetbrains.com/issue/WEB-1926 and discussion on stackoverflow (mocha + webstorm - error message broken)
To fix the case described in question we can run jasmine tests directly by jasmine-node command (skipping grunt).
We have to set up new "Run/Debug Configuration" based on "Node.js" pre-conf.
Node interpreter (as usual):
C:\Program Files\nodejs\node.exe
Working directory: project root,
JavaScript file:
node_modules\grunt-jasmine-node\node_modules\jasmine-node\lib\jasmine-node\cli.js
This is for my case (using grunt-jasmine-node). We can also provide path to cli.js of jasmine-node installed globally.
Application variables:
--verbose src/test/js
Of course the last one is a path to directory of tests in my project. Here we can specify list of files or use other jasmine-node commands and parameters.
The problem that process.exit() does not wait the stdout. You should defer the exit call with one tick, that's all.

Resources