Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Node globals are not accesible in module definition #89

Closed
ghost opened this issue Apr 8, 2011 · 10 comments
Closed

Node globals are not accesible in module definition #89

ghost opened this issue Apr 8, 2011 · 10 comments

Comments

@ghost
Copy link

ghost commented Apr 8, 2011

There was a discussion about this issue a while ago, which resulted in this file: http://www.requirejs.org/temp/dirfile/r.js. However, it seems those changes have not been committed to the main branch.

It it possible to have all of http://nodejs.org/docs/v0.4.5/api/globals.html available?

@jrburke
Copy link
Member

jrburke commented Apr 8, 2011

I believe I changed the approach to Node integration since that first dirfile file was put up -- I decided it was better to not try to keep up with node internals, which would require constant gardening. That said, I expect most of those globals to work except for the items on require, and for __filename and __dirname. However, CommonJS specified that "module.uri" has the path to the file, I expect that can serve the purpose of __filename, and means the code would be more portable to other environments like Rhino.

Is it __filename and __dirname you are missing or something else?

@Xavura
Copy link

Xavura commented Apr 8, 2011

I also noticed that __filename and __dirname were missing. Could those be added, at least?

@jrburke
Copy link
Member

jrburke commented Apr 8, 2011

I would like to understand the use case some more, it may be something I have not considered before:

Are you authoring your own modules with a define(){} wrapper that use them, or have you converted existing modules created for Node to have a define() wrapper?

@ghost
Copy link
Author

ghost commented Apr 9, 2011

No, I am not intending to convert existing Node modules. I am trying to use define() for my own modules and currently need only __dirname. The use case is similar to that presented here http://expressjs.com/guide.html#configuration.

As I am new to Node and RequireJS, there might be other ways to get current module path/uri, which I don't know about. Any hints would be appreciated.

Regarding other global references, the process object seems to be reachable via global (global.process). setTimeout(cb, ms) and friends are available from Timers module (http://nodejs.org/docs/v0.4.5/api/timers.htm). The remaining ones look unnecessary at the moment.

@neonstalwart
Copy link
Contributor

i think module.filename will have the filename and then you can use require('path').dirname(module.filename) if you really need it. i haven't verified - this is just from looking at https://github.com/joyent/node/blob/master/lib/module.js

@ghost
Copy link
Author

ghost commented Apr 9, 2011

Unfortunately, module is undefined inside define()'s callback and I can't find anything that would expose the filename.

@jrburke
Copy link
Member

jrburke commented Apr 9, 2011

If you do the following, you should be able to get the path and dir for the current module:

define(['module', 'path'], function (module, path) {
    console.log("module's path is: " + module.uri);
    console.log("module's dir is: " + path.dirname(module.uri));
});

This has the benefit that, if you provide a path module for the browser, that it could run in the browser with RequireJS.

@jrburke
Copy link
Member

jrburke commented Apr 9, 2011

I should note: that 'module', 'exports', and 'require' are all special dependency array values that map to the CommonJS ideas of module, exports and require.

@ghost
Copy link
Author

ghost commented Apr 9, 2011

I should note: that 'module', 'exports', and 'require' are all special dependency array values that map to the CommonJS ideas of module, exports and require.

Didn't know about those. Thanks for clarification. I think the issue can be closed if nobody objects.

@jrburke
Copy link
Member

jrburke commented Apr 9, 2011

Closing per opener's request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants