If an explicit cwd is provided, try searching for the module there if it could otherwise not be determined

The current implementation chooses to search for the module in the following order:

1. <configPath directory>/node_modules/<module name>
2. main file in <configPath directory>/package.json

I have a need for the search to continue. Perhaps if these first two searches turn out unsuccessful, these 2 steps could be repeated in the CWD (in place of the configPath) if an explicit one was provided. So the process would be to search for the module in the following order:

1. <configPath directory>/node_modules/<module name>
2. main file in <configPath directory>/package.json
3. <provided cwd>/node_modules/<module name>
4. main file in <provided cwd>/package.json

[grahamaj]

This is true, but is not the case when a configPath is set.

In my specific situation, I have a configPath file that is version controlled in directory A and want to run it in context of directory B which is not version controlled. Directory B contains my target library in the node_modules directory. I expected that when I pass both the configPath and the cwd that it would search for my target library in directory B since I explicitly told it that I am working there. What happens instead is that it only tries to look for the target library in directory A. This is because configBase is defined and so the said line of code (https://github.com/js-cli/js-liftoff/blob/master/index.js#L93) chooses to assign configBase to the basedir property. The node_modules aren’t there and neither is a package.json file. This directs to code to https://github.com/js-cli/js-liftoff/blob/master/index.js#L110 where the modulePath is never assigned.

I realize that in most cases the configPath file will be co-located with the target library, but I also see no harm in searching the cwd path after the configPath directory is searched and the code failed to locate an appropriate modulePath.

[ams-tschoening]

I’ve ran into the same problem with the following directory layout:

• app
• build
• config
  • Gruntfile.js
  • stealConfig.js
• lib
  • bower_components
  • node_modules
  • bower.json
  • package.json

Grunt uses LiftOff these days like the following:

  Grunt.launch({
    cwd: options.base,
    configPath: options.gruntfile,
    require: options.require,
    verbose: options.verbose
  }, function (env) {

But had the same problem in the past on its own as well. The workaround then was to simply set the current working dir of the process:

gruntpath = findup('lib/grunt.js');

With switching to LiftOff this doesn’t work anymore and the current working directory is not recognized during searching for modules, even though it’s provided on the shell using --base (or even --cwd). But one can work around that using package.json in the config-dir: That file is always checked in case a configBase is available, but a requested module has not been found and only needs to contain the following in my directory layout:

{
	"name": "grunt",
	"main": "../lib/node_modules/grunt"
}