Unitech/pm2-interface — pull request #3 by bretcope (2013-11-22 01:11:38+00:00)
Title: Remove Arbitrary Parameter Limit

This change is to support the `God.prepareJson()` method in [another pull request](https://github.com/Unitech/pm2/pull/186) which accepts an optional middle parameter `cwd`. However, there is no reason why other God methods couldn't eventually make use of this ability as well.

#### Reasons for the Change

When you use PM2 to startup apps with a json file `pm2 start process.json`, it is understood, and expected, that your cwd will be the directory where you typed the command. However, when you start apps using pm2-interface, the cwd is not that of the script using pm2-interface (invoking script), it is actually the directory where the PM2 daemon is running (which could be anywhere). Since most apps defined in a processes.json file use relative paths, this is a problem.

This could be seen as the problem of the invoking script, and require it should adjust the app object before sending it. For example:

```javascript
var apps = require('./processes.json');
for (var i in apps) {
apps[i].script = path.resolve(process.cwd(), apps[i].script);
ipm2.rpc.prepareJson(apps[i], cb);
}
```

But then it would also be the responsibility of the invoking script to adjust `out_file`, `error_file`, `pid_file`, and any other properties which may get added at a later date. This would drastically reduce the usefulness of `prepareJson`.

So, the other option is to let the invoking script explicitly specify a desired cwd.

#### Why not an optional Property instead of Parameter?

One way you could pass a cwd would be to attach it to the app object.

```javascript
var apps = require('./processes.json');
for (var i in apps) {
apps[i].cwd = process.cwd();
ipm2.rpc.prepareJson(apps[i], cb);
}
```

There were a few reasons I wanted the `prepareJson` method to accept an optional parameter, rather than include `cwd` as an optional property of the app object:

1. It is not part of the processes.json format, though perhaps it could be eventually. If it was, we would have to decide whether or not relative paths would be allowed or not, and if they were, you would still need to resolve it using a base cwd which would, again, put more implementation burden on the invoking script.
2. Listing it as a parameter makes it more obvious that passing your own cwd is probably something you should consider doing.
3. `prepareJson` may eventually accept an array of apps instead of only one at a time, and it would be easier to pass the option once instead of having to attach it to each app object.
4. This removes the barrier for other God methods to accept additional/optional parameters in the future.

#### Future Compatibility

I can see an argument for instead of `prepareJson( app, [cwd , ] callback)`, using `prepareJson( app, [options , ] callback)` where `options` might be something like `{ cwd: '/home/user/test' }`. Perhaps this would be better, but cwd would be the only meaningful property for the foreseeable future, so I like the shortcut of using a string instead of an object.

Even if the cwd parameter was converted to an options parameter, it would be very easy to implement backwards compatibility.

```javascript
if (typeof options === 'string')
options = { cwd: options };
```

So this seems like a non-issue to be, but I wanted to address it.

#### Thoughts?

As with the prepareJson pull request, let me know your thoughts and whether you would consider merging this with or without modifications.