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

[grahamaj]

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

1. <configPath directory>/node_modules/
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/
2. main file in <configPath directory>/package.json
3. <provided cwd>/node_modules/
4. main file in <provided cwd>/package.json

[phated]

I'm confused by this issue. If a cwd is provided, we resolve from there, see: https://github.com/js-cli/js-liftoff/blob/master/index.js#L93

[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.

[grahamaj]

Perhaps some code would better explain it. (See grahamaj@4245300) I am not sure if this code is perfectly correct, though the unit tests still pass. I am not familiar enough with the rest of the code to know how to fully account for the assignment on line 107 of the original code.

[tkellen]

Heya @grahamaj, I understand what you're saying and I agree that this should be possible. Would you please open a PR with your changes?

...as for what this block is doing:
https://github.com/js-cli/js-liftoff/blob/master/index.js#L97-L112

Imagine for a moment that you had gulp-cli installed and were working on gulp itself. Since gulp-cli uses liftoff, and it tells liftoff that a local copy of gulp is needed, liftoff needs to be able to detect this. If gulp itself had a gulpfile, the dependency required to run it wouldn't be in node_modules... we are working inside the dependency itself. So, we look at the package.json to see if this is the case, and if it is, use the main property to find the entry point.

[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"
}