require('remote'); breaks javascript packers

[palavrov]

It is not possible anymore to use app-rooth-path with javascript packers (browserify for example) because of hidden dependency to electron internals:

// Defer to main process in electron
if ('type' in process && 'renderer' === process.type) {
        var remote = require('remote');
        return remote.require('app-root-path').path;
}

This is what I got when using nexe (which uses browserify internally)

Error: Cannot find module 'remote' from '.......\node_modules\app-root-path\lib'

My workaround for the moment is to stick with version 1.0.0 but it will be a pity in long term to do it.

[ctrlplusb]

Same issue applies with the latest version, substitute remote for electron.

[palavrov]

My final solution was to remove app-root-path - because actually it doesn't work properly after browserify (in my case this is side effect of using nexe).

The problem was that __dirname holds its value as it was during the compilation even when you move the app to somewhere else.

The only thing that I need was to get where the app directory is so my workaround was this:

var path = require("path");

var isNode = path.basename(process.argv[0]).toLowerCase().startsWith("node");
var rootPath = path.dirname(process.argv[ isNode ? 1 : 0]);

May be this will solve your problem too or may be it can be added to app-root-path instead using of complicated logic and dependency to third party packages.

[inxilpro]

I'm working on a release that will publish an alternate browser script that is just a shim. That should mean that you can use it inside a browser app and ir at least won't break things.

[inxilpro]

Take a look at version 2.0 — does that fix your issues with browserify?

[palavrov]

Version 2.0 still depends from electron and fails with browserify/nexe bundling.

Note that nexe is using browserify for the server and not for the browser so the provided shim doesn't help at all. It is kind of electron but without the webkit - just packaging everything in one executable.

Probably the same problem will be for nw.js or other node compatible bundlings.

I.e. until app-root-path depends on __dirname the problem with nexe will remain.

[inxilpro]

I see. The most recent change should help with browserify, but not nexe. I'll dig around a bit and see if I can find a solution there. I also don't love the electron-specific code. I'm going to see what I can do there, too.

[palavrov]

I was thinking about that too and think that conceptually we are looking for different things depend the app:

• the directory where the app resides
• the app node_modules directory which can be:
  • a subdirectory of the previous one
  • completely missing in case of bundling
  • something in between - some modules are bundled, some are in the subdirectory
• platform agnostic system wide or per user app directory to keep data assets

Initially I was trying to use app-root-path to get the app directory to keep system wide data in it. Then I replace it with this monkey workaround but still I'm not happy how it is solved. May be we will need completely new module to provide all these directories or to add more logic to app-root-path to support that. Just my 2 cents ...

[inxilpro]

Can you give me a little more detail about how you're using it with nexe? My understanding is that nexe just packages the whole app into a single file, and doesn't support dynamic require() statements, so a tool like this would never work with it.

[inxilpro]

I ended up refactoring the electron logic a tiny bit, and while I did that, I also made the require statement for electron dynamic, which should help address this issue.

[inxilpro]

(See release 2.0.1)

[palavrov]

Yep, nexe is doing exactly that but first it packs everything with browserify. Then in run time someone (nexe or browserify) emulates __dirname passing the compile time directory i.e. the directory where the sources were during the bundling step i.e. all logic based on __dirname will fail.

My usage of app-root-path & nexe was trivial - app-root-path was dependency and was used to create directory relative to the app path. At one moment I realize that wherever I move the build executable file it was not creating this directory at expected place but was going all the time to the compile time directory. IMHO this behavior will be the same with all such packers and bundlers because they don't know what to do with __dirname, how to emulate it. May be the best will be if they just fail when __dirname is used to avoid unpredictable or weird results.