`undefined` in output, if nodeunit is also a (direct) dependency of my project about grunt-contrib-nodeunit HOT 8 CLOSED

Hey thanks for reporting! Looking into this...

from grunt-contrib-nodeunit.

So it's either the case that:

1. The user has grunt-contrib-nodeunit listed as a dependency, and not nodeunit as a dependency.
2. The user has both grunt-contrib-nodeunit and nodeunit installed as a dependency (probably the more likely case, and the problem listed by @weemonger).

I wasn't aware that if you are dependent on both A and B, and A requires B, that it won't install its own copy of B (probably unless you have specific version requirements that differ).

#23 solved case number 1 above.

My thoughts are we could simply also look for ../../node_modules/nodeunit/bin/nodeunit.json instead of just ../node_modules/nodeunit/bin/nodeunit.json. Shouldn't that cover all cases?

from grunt-contrib-nodeunit.

PR #25 should fix it.

from grunt-contrib-nodeunit.

It is possible that the nodeunit package is even further up the directory tree.

I think of a grunt-collection-plugin:

myApp - package.json:

"dev-dependencies": {
   "a-grunt-collection-plugin": "~x.y.z",
   "nodeunit": "~a.b.c"
}

a-grunt-collection-plugin - package.json

"dependencies": {
   "grunt-contrib-nodeunit": "~d.e.f",
   ...
}

grunt-contrib-nodeunit - package.json

"dependencies": {
   "nodeunit": "~a.b.c"
}

The result dependency-tree of my-app should be:

myapp
└── node_modules
   ├── a-grunt-collection-plugin   (version: x.y.z)
   │   └── node_modules
   |       └── grunt-contrib-nodeunit   (version: d.e.f)
   └── nodeunit   (version: a.b.c)
       ├── bin
...

Could require(nodeunit.json) be used to find the file, regardless where in the node_modules-tree it is?

from grunt-contrib-nodeunit.

I don't think require() can be used to get an arbitrary file from another module (though I haven't tested it).

Theoretically we could use the same logic that require() does, going infinitely up the tree looking for node_modules\nodeunit\bin\nodeunit.json.

Are there current cases of grunt plugin collections that would need this logic?

from grunt-contrib-nodeunit.

You are right, nicjansma. require() can't be used like that.

I think the easiest way is to ask @caolan to export the nodeunit.json file as 'defaultOptions' of nodeunit,
so it can be used like that:

nodeUnitDefaults = require('nodeunit').defaultOptions;

Regarding your last question, if there are current cases of grunt plugin collections with such a need:
Currently - I can't say, but I am planing to write one myself (at least for my current employee) to encapsulate our standard build process and configuration, to use it easily in many projects.

But if you don't want to support this case, it is fine for me - I can help myself, and define the defaultOptions in the task config.

If I find the time this week, I will contact @caolan and/or create a pull-request for nodeunit to export the nodeunit.json file.

If nobody else is interested in this issue, it can be closed, imho.

Thanks for your time and effort.

from grunt-contrib-nodeunit.

Hi,
I stumbled over this interesting snippet

  var fooVersion = require('foo/package.json').version

in an example for optionalDependencies on https://www.npmjs.org/doc/files/package.json.html.

A short test, ala

nodeUnitDefaults = require('nodeunit/bin/nodeunit.json');

was succesfull.

Expect a PullRequest after a more serious test.

Any tips, regarding a unit-test for this, are welcome.

from grunt-contrib-nodeunit.

Published 0.3.3 that should fix this issue for you. It would be great for Nodeunit to "export the nodeunit.json" but it's up to them. Feel free to PR to make the defaults load better if necessary.

from grunt-contrib-nodeunit.