I'm trying to write a debugging framework for node.js and am having a hard time figuring out how to get the full path to a core module file like fs.js.
I've heard it's in the /lib folder of the node installation, but I'd need to get this from the code in a consistent way for a variety of install situations (including windows).
I've tried taking a look at the process and process.env values for something like a node install path but can't see anything that immediately pops out at me.
To find where the installed node executable is located you can look at the process.execPath which gives the absolute path to Node executable.
To find where a certain module is located you can use require.resolve(module);
However I think the global modules are not directly accessible from the filesystem as other regular modules since they seem to be cached somewhere within the executable.
Related
When I did node myfile.js I got an error that a module was not found. I checked module.paths like this:
$ node
> module.paths
The path where the module is installed showed up and I could require the module:
$ node
> require("the-module")
So I added console.log(module.paths) to myfile.js to see if module.paths was the same. It was not.
What is going on?
EDIT:
It was a bit more complicated.
The module.paths are different, but that does not seem to be the problem. The path where the-module is installed is in the list.
When I add require("the-module") in myfile.js it works as expected. However I do require("c:/path-to/other-file.js") and from there I do another require("the-module"). This require fails.
EDIT 2:
module.paths is other-file.js is different. Why? (And the path where the-module is installed is not in this list.)
You can see all the rules for how require() loads files when you don't specify a full path here.
When you specific only a filename, as in require("the-module"), node.js looks in the node_modules sub-directory below the directory that the current module you are calling require() from was loaded. It is done this way so that a module can have its own set of dependencies and can load them relative to it's own directory without regard from where it is in the file system.
So, if the module you are calling require() from was in c:\myprojects\team\module1 and from within a file in that directory, you call require("the-module"), then node.js will look in c:\myprojects\team\module1\node_modules to find the-module.js.
Similarly, any path that starts with ./ is relative to that same directory, but allows you to reference files in the same directory itself.
node.js does not dynamically add paths to a list of search paths. It sounds like you have an expectation that as you access various directories they are somehow automatically added to a search path. That's now how it works. The rules for where require() looks for relative paths are all spelled out here.
Also, keep in mind that there is not just one module variable across all of node.js. There's a different one in each file that you load in node.js so module.paths very well may be different in each one. In reality, most node.js developers never use module.paths in any way. If you just follow the rules for how relative paths work for require(), you will get what you expect and need.
I have a node script which uses command line parameters using the module commander.
I want to pack it with pkg, but I am running into some trouble.
Normally I would execute my script with:
node index.js --file ./test.csv
but the file argument could point to any folder in the user's filesystem.
I have looked into configuring the assets and scripts attributes for pkg in package.json, but it looks like you need to specify a folder in there, such as:
"pkg": {
"scripts": "build/**/*.js",
"assets": "views/**/*"
}
How can I make a zeit-pkg packged node script aware of any possible location in the filesystem?
I am simply building with pkg package.json , since in package.json I have the entry:
"bin" : "index.js"
In your pkg-packed source, add this in the beginning:
console.log("process.cwd() = " + process.cwd());
When you run your packaged exe this will tell you what
your executable sees as its working directory. You can
then interpret any relative arg-paths of your application
(like "./index.csv") relative to that.
It seems based on my experiments that pkg-applications have
full access to the file-system as long as your program knows
the absolute paths of the files you want to read or write
or even "require".
The only tricky thing seems to be relative paths.
The reason is that pkg wants you to be able to package
resource/asset -files into the executable and then access them
like you would any file at runtime. That is actually a
great feature but often more than you need.
If you don't need to package any (extra) files into your
executable then file-system access should be simple and
work just normally with absolute paths. You just need to
know "where you are" if you want to use relative paths.
I'm not affiliated with the pkg project so my answer is
not authoritative in any way. I hope zeit would put more
documentation about the file-system access into their site,
especially cross-platform. After doing some experimentation
myself it just seems accessing files by their absolute paths
works, on Windows.
Always feel stupid asking here because people are always confused with my questions, or I have a dumb problem, but, I'm working on a program in node.js and the text editor I'm using (NP++) doesn't seem to like to save files in the system32 directoy, (The directory where my modules are), and that is where my script is as well. (So I have .../.../node_modules/(modules) and .../.../node_modules/script.js) this becomes a pain when I want to edit the script, I have to clone the script to my desktop, then edit it, then overwrite the one in the node_modules directory. I tried saving the script to my desktop and running it, but it just gives me an error of module not found. (In my script I have the modules as var example = require('example.js')) Is there any way I can get it to get the modules from the node_modules directory, while keeping the script file somewhere easily accessible and editable? (i.e desktop?) (Sorry if this is confusing, not the best at these kind of things)
I'm not 100% sure that this is what's happening because I haven't used npm on Windows, but it sounds to me like you're installing your dependencies globally using npm -g. The more proper way to use Node is to install your dependencies locally, using npm without the -g flag. That way your dependencies get installed in your current working directory.
For example, let's say you've saved your project in a directory on your Desktop, and your script uses require("lodash"). If you cd to your directory and run npm install lodash, then the lodash module will be available to your script.
My problem is a little complicated but I'll try:
I have a node.js application that needs to be completely prebuilt and bundled alongside standalone node.js (specifically 4.4.5 LTS), zipped and deployed to offline CentOS 6/7 machines, meaning I cannot do npm install, and no gcc/g++/python so I cannot do things like node-gyp rebuild.
Everything is working correctly except this module: ibm_db.
It's compiled with node-gyp after downloading the db2 cli drivers, but basically it's supposed to work like the regular DB2 client except all its dynamic libraries, binaries etc. are inside the module path itself (node_modules/ibm_db/installer/clidriver).
If I deploy the bundle (which includes all node modules in the tarball, including ibm_db) to another machine, it's probably going to sit on a different path from the machine on which I built the bundle. When I try to run the app like this: ./node app.js (here node is a symlink to the standalone node binary inside the unpacked bundle) i get this error:
Error: libdb2.so.1: cannot open shared object file: No such file or directory
Now, I can clearly see that libdb2.so.1 is inside node_modules/ibm_db/installer/clidriver/lib but the paths in bindings.gyp all use the original paths on the build machine which don't match, so I assume this is where the problem lies.
I can easily just add that path with ldconfig and it would work, however the user profile installing the app will not have superuser access so it's not a real option.
I tried setting the environment variable LD_LIBRARY_PATH but node.js deletes this entry from process.env on startup, and even if I programmatically set it like process.env.LD_LIBRARY_PATH='...'; it doesn't seem to do anything.
Is there any way to modify the library path for a compiled module without recompiling/rebuilding it? If it's possible I would assume that would be the easiest solution, but I couldn't find a way to do it.
I used the steps explained in this page: http://nodejs.org/api/addons.html and successfully created a addon.node file using the node-gyp tool. it works fine and it's a wrapper of a c++ static library.
Now I want to distribute this, I created the package.json file using:
npm init
and test it using "npm install . -g" but it tries to recompile the module which will be difficult to achieve because it will require the libraries that I'm embedding into the .node file, is it possible to distribute the .node file that I already compiled in my system?
How can I include the compiled .node file into the npm package and upload it to the npm registry. I'm sure I'm just one step to made it, but I dont know where to start.
I read about the dependencies, but seems that it's suited when your module depends on other modules, and not with your own .node file.
Thanks for your help.
ok, I finally did what I wanted to achieve, here're the options in case someone else needs this:
To avoid the compilation you could create a new folder and copy the package.json in there, along with the .node file, I didn't find this, just tried and it worked.
Provide the required libraries to allow the user his own compilation.
Although the first one worked well, I will need to create a package for windows, linux, mac, etc. Which looks very odd to say: "if you are in linux use: npm install xxx-linux", so I decided to adjust my library to allow the user the module compilation.
To do this I created a "client-dev" installer that has the required libraries precompiled, as long as the include headers required, then created the node module to be compiled using the preinstalled libraries and headers. I will need to add a help in my website to explain that, in order to install the module, the user will need to install the dependencies first using apt-get, windows installer, or mac pkg.
Although this works for me, I don't know if that will be maintainable in the long run, but I didn't find a better way to do this. (the only link that finally enlightened my goal was one saying: "if you're going to use node modules with precompiled libraries you will have nightmares", anyway... I prefer that instead of doing a full implementation in node js from scratch and maintain version for java, c#, nodejs, php, etc.