App fails to start if not invoked from the app root. about kraken-js

[totherik]

FYI: Accessing the main module

Also, consider that this breaks down when process managers are involved. For example, when using PM2 the main module is not the file you think it is.

Additionally, this was built to start in the current directory and traverse upward, looking for a valid kraken application to support the experimental mounting of apps. If you'll notice, it explicitly DOESN'T use process.cwd(), but starts with the current file location (inside node_modules, hence the .); Please see the root resolver to get a better understanding of what's going on here.

EDIT: It doesn't use process.cwd() unless a valid kraken app isn't found. If there's a bug, it might be there.

[lmarkus]

Yep, I was just going to point out what you edited.
I was looking through rootResolver and I think the issue might be with how we're using the isKraken(obj) function in this loop.

The parameter being passed by rootResolver wants to compare the prototype of module.exports for whatever module is being evaluated in the loop, against the kraken object (Or the unicode yingyang).

Because of this, I don't think this condition will evaluate to true during the loop, so it eventually stops when there are no more modules to traverse (current.parent=null).

At this point, since root was never defined, the function returns process.cwd()

On my solution, I had not considered other startup methods for the app, so good callout.

Will continue looking at this tomorrow.

[kethinov]

rootResolver seems like a pretty heavy way to determine the location of the app's root directory. Why not examine module.parent.filename from within kraken to get the directory of the file which required kraken?

[kethinov]

Also, is pm2 the recommended way to deploy kraken to a live server? Do you prefer it over, say, node-forever? And are there other such tools worth considering as well?

[totherik]

rootResolver is heavy because it was intended to support more complex application composition. If we choose not to pursue composable, mountable apps then much of this code can be deleted (with no argument from me). module.parent.filename is not necessarily the module that required a file, but the file that required said file/module, and with composition, depending on the version of kraken, it might not be what you're looking for.

The rub here is composition. If I create a kraken application and publish it as a module, depending on the version of kraken I depend on, I may have my own "application root" (with my own copy of kraken, templates, etc.) which is in a nested directory of the actual application root, but this nested directory (within the top level node_modules) contains all my application context. @jasisk and I spent a good amount of time working through possible scenarios creating the "heavy" resolver to be resilient to arbitrarily composed applications. The complexity was added for a specific use-case, but if it's deemed unnecessary, I'm more than happy to remove it.

Also, pm2 isn't necessarily the recommended solution, but it's an example of a situation where a script or application runner defines an alternate require.main.filename crushing all assumptions of what truly is the application root. BTW, there is a flag in pm2 which indicates it may patch require.main.filename, but last I checked it wasn't available for use.

[jeffharrell]

Is this an issue anymore as of 0.7?

[lmarkus]

Nope...