preferably via global.__dirname
also see the discussions:
https://groups.google.com/d/topic/node-webkit/IwGzluFC9iU/discussion
https://groups.google.com/d/topic/node-webkit/cMjpP4ptrWg/discussion
What's wrong with a good old process.cwd()?
@Mithgol thanks for the hint :) We'd like to also support global.__dirname
I hope you are planning a聽getter that would call process.cwd().
Some other solution (like actually updating global.__dirname _each聽time_ the聽cwd changes) could slow聽down the聽application unnecessarily.
I see. Could you please reply in the mailing list as well? So the OP would know about this tip.
I聽do聽not have an聽active Google聽Groups account, sorry.
You could give the original poster a聽hyperlink to聽this聽issue on聽GitHub.
Alternatively, you may point him to http://nodejs.org/docs/latest/api/process.html#process_process_cwd because he聽may聽find process.cwd() suitable聽enough for聽his聽needs.
__dirname should not update whenever process.cwd() changes. The working directory and location of the script are two very different things.
At the very least, this should be documented, as it's a departure from Node's API.
For now, I suppose you could do
global.__dirname = process.execPath.substr(0,process.execPath.lastIndexOf('/'));
Thank you for explaining where I聽was mistaken.
According with the Node.js behaviour, __dirname & __filename doesn't have to be global, they are proper to the current script/module.
Furthermore, parse process.execPath seems to be a bad idea, because your app is targeted by the package.json but may be everywhere.
I think, it's an implementation bug, like if the module loader doesn't share these vars.
My solution, waiting an upgrade, https://github.com/rogerwang/node-webkit/issues/1643. ;)
Not supporting __dirname is pretty bad for node.js applications. Any update on this? Is there an overview about what node-webkit supports in terms of node.js features? __dirname seems pretty basic. Most applications use it to specify e.g. view-folders (express).
__dirname works in Node.js modules, i.e. in聽JavaScript聽code that聽was聽called with require().
__dirname doesn't work only in聽WebKit scripts, i.e. in聽JavaScript code that was called with HTML <script src="...">, or聽jQuery's $.getScript(), or聽any聽other similar method.
I see, thanks for the clarification. As a related note, when I do a "console.log(__dirname)" from within my nodejs script, is there any way to see it somewhere in nodejs-webkit console?
It should just work.
It聽works for聽me:
module.exports = __dirname;
console.log('Hello ' + __dirname);

Can this be closed? @bpasero @Mithgol
I agree should be closed.
I agree as聽well.
@Lcfvs , what did you mean in "process.execPath seems to be a bad idea, because your app is targeted by the package.json but may be everywhere".
(It works fine for me locally, what am I missing here? I'm trying to avoid an error on a user's machine...)
Per my last comment, I realized what you meant. When you run node (while supplying it some js for example), process.execPath returns the location of the node.exe, regardless of the location of the app. However in my case, when distributing my nwjs app, the app is bundled together with the nw.exe, and so process.execPath returns the desired result.
For those looking for the directory of the index file name and not the nw executable, use:
global.require.main.filename
Note that if your app is organized into subdirectories, changes the cwd, or uses a different location for the nw executable, the directory of the currently running WebKit script may not correspond with the above suggestions (your app's main entry point .html file, process.execPath, or process.cwd())! The trick of using var __dirname = require('./dirname.js') in the same directory as the WebKit context's .js file is nice, but may result having to litter dirname.js files around.
I suggest using:
var __dirname = path.dirname(document.currentScript.src.slice(7));
or if you don't feel like doing a var path = require('path');:
var __dirname = document.currentScript.src.slice(7, document.currentScript.src.lastIndexOf('/'));
The content of document.currentScript.src is a nice absolute file:// url. The slice(7) strips the file:// scheme off.
Sorry, I missed the solution for this issue. How could I get current working directory?
process.cwd() --> gives some temp folder: /tmp/.org.chromium.Chromium.sXz93T
@drom to get the current working directory when the app was started before NW.js changes to the directory containing the app, on Linux & OS X process.env.PWD and on Windows use process.env.CD.
@polpo I can't find any sign of process.env.CD under Windows.
Note that starting with nw13, global.__dirname now contains the proper dirname of the current .js file, and my comment above from Nov 4, 2015 no longer applies.
@polpo That's incorrect. __dirname still does not work properly, at least in the browser context. From the Node.js documentation:
__dirname isn't actually a global but rather local to each module.
For instance, given two modules: a and b, where b is a dependency of a and there is a directory structure of:
/Users/mjr/app/a.js
/Users/mjr/app/node_modules/b/b.js
References to __dirname within b.js will return /Users/mjr/app/node_modules/b while references to __dirname within a.js will return /Users/mjr/app.
In Node.js, __dirname is local. In NW.js, __dirname is global, which makes no sense. So if I start root/index.html which references root/scripts/app.js, and then call global.__dirname, it should return root/scripts. Instead, it returns root/.
NW.js should bind the variable dynamically in the context of a script when it's evaluated.
FWIW (and I'm not using nw.js at the moment), here's my own polyfill to get the script's directory:
Assumes document.currentScript support (for which there is an IE6-10 polyfill but IE11 won't work as per the polyfill site):
const baseURL = typeof __dirname !== 'undefined'
? __dirname
: (() => {
const src = (document.currentScript && // May not be present if running from say console
document.currentScript.src
) || location.href;
return src.replace(/\/[^/]+\/?$/, '');
})();
Also, FWIW, there is a JavaScript proposal (currently at stage 3) to get this from within ES6 modules; see http://2ality.com/2017/11/import-meta.html .
Happening problems with __dirname here: https://github.com/nodejs/node/issues/18267
Most helpful comment
Note that starting with nw13, global.__dirname now contains the proper dirname of the current .js file, and my comment above from Nov 4, 2015 no longer applies.