In a Node package.json file, you can map multiple executables to the PATH environmental variable on a global NPM install (npm install -g):
"bin": {
"foo": "./bin/foo.js",
"bar": "./bin/bar.js"
},
I have a unique project that requires mapping existing PATH variables on Operating Systems that do not have it. For example, I want to add a command named grep to PATH, if and only if it is being installed on a Windows computer. If the computer is running any other OS, the NPM installation will obviously fail.
Is there any way to run logic that pre-determines what bin options are available in the installation?
Oh snap - I just had an idea!
Would this work:
Parent module has npm (programmatic version) as a dependency.
On global installation, run a post-install script as declared in the package.json of parent module.
Post-install script does a check on the system to see which commands exist. This would be more mature than "Windows or not Windows" - it would try to exec a list of commands and see which ones fail.
For every command that doesn't exist, post-install script programmatically runs npm install -g on all sub-modules (one for each command, such as grep).
This would take a while and the npm module is huge, but it seems like it would work. No?
There doesn't seem to be a way to do this directly through package.json, but it might be possible (and desirable) to do something like:
Make a separate npm module for each executable you want to register (eg my-win-grep).
In the my-win-grep module, implement the executable code you want to run, and register the PATH/executable value in this module.
In the package.json for my-win-grep, include an os field that limits it to installing on windows.
In your original module, list my-win-grep as an optionalDependency.
In this way, if someone installs your original module on Windows, it would install my-win-grep, which would register an executable to run under the grep command.
For users on other systems, the my-win-grep module would not install because of the os requirement, but the main module would continue to install because it ignores failures under optionalDependencies. So the original grep executable would remain untouched.
Updated question
This approach does sound like it should work - as you say, the npm dependency is pretty large, but it does avoid having to preform additional symlinking, and still has the benefit outlined above of having each piece of OS specific functionality in a separate module.
The only thing to watch for, possibly, in the programmatic npm docs:
You cannot set configs individually for any single npm function at
this time. Since npm is a singleton, any call to npm.config.set will
change the value for all npm commands in that process
So this might just mean that you can't specify -g on your installs, but instead would have to set it globally before the first install. This shouldn't be a problem, but you'll probably need to test it out to find out exactly.
Lastly...
You might also want to have a look at https://github.com/lastboy/package-script - even if you don't use it, it might give you some inspiration for your implementation.
Related
I am currently working on a project at a large company, and according to the project I am working on, every time I want to quickstart the app, I would need to first run the command npm install and then run all the additional compiling instructions, but the problem is that running npm install can take a long time, and that is why I am wondering if it is necessary to run this command every time I make a change to the code, and then want to compile and run it.
What exactly does npm install do? If you could explain to me in terms of how we compile and run java code i.e. javac bob.java && java bob and try to make analogies on that basis, that would greatly help me understand the concept. The way I am currently thinking about it right now is that npm install kind of runs like how javac runs, but I am not sure if that is correct. Thanks in advance!
NPM Install
npm install simply reads your package.json file, fetches the packages listed there from (usually) https://www.npmjs.com/, and sometimes engages in the build steps for those packages.
So you only have to run npm install when you change your package.json file, and need to fetch new dependencies.
Keep in mind that npm install --save <packagename> (or npm install -S <packagename>) will update your package.json and run npm install all in one line!
You can view the results of your npm install inside ./node_modules/.
To compare to java
This might be a helpful resource if you're trying to get stuff done: Getting Started with Node.js for the Java Developer
Javascript is not a compiled language, unlike java. When you invoke javac, the java compiler reads in all your .java files, compiles them to java bytecode, and then writes them to .class files, which can then be bundled together into a .jar for execution.
Javascript doesn't do any of this! When you invoke node foo.js, the node executable wakes up, reads foo.js, and gets to work invoking it line by line**. Node does other cool things, including maintaining an event loop (which allows it to operate "asynchronously", and allows it to be very efficient as a webserver-- it doesn't sit around waiting for requests to complete, it carries forward with the next event in the queue.
Node also performs JIT and optimization, these details allow it to improve the performance of sections code it notices are running "hot".
Note also that node.js uses the V8 javascript engine (also used in Google Chrome). Really everything I've said above is handled by V8.
(** Technically there is a syntax checker which is run first, before execution. But this is not a compile step!)
It is not necessary to do "npm install" each time you want to compile. You just need to do it when you change the dependencies of your project.
NPM basically is the package manager for node. It helps with installing various packages and resolving their various dependencies. It greatly helps with your Node development. NPM helps you install the various modules you need for your web development and not just given you a whole bunch of features you might never need.
When you start an app, it comes with a package.json file. That package contains the list of node_modules you are gonna need. Whenever you enter npm install, what you are doing is to download that list of node_modules. So yeah, you have to download the modules all over again.
#NOTE: In your project, you have a file called package.json. this file is responsible for holding track of your project's dependencies. That's why you have to install it every time#.
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.
Does anyone know how to configure location of global repository?
My global repo is somewhere under $HOMEDRIVE/$HOMEPATH/blahblahblah
and all my packages are being installed under that place fopr global reference
but I want to park it somewhere specific and secret like the docroot of my appserver ? so I can operate demos and proof-of-concepts and prototypes ands show them off
can you tell me how I can configure the path to my global repository? I am on windows7 which is thoroughly supported and chmod chown issues are not as prevalent on linux
is this directory anchor controlled by a designated variable within NPM?
is this variable ever referenced by javascript modules indiscriminantly? i would hope not
I assume this variable is within the NPM tool itself.
what about bower... would bower operate the same configurable? or is bower a different animal and place.
is bower a subset of npm? anmd of so does it operate the same configuration as npm?
thank you
See the npm docs about the folders. It states that the global modules are installed under a configured prefix. You can get it from the npm config comand:
npm config get prefix
And you may change it with a similar command:
npm config set prefix /path/to/my/global/folder
However, modules are usually installed globally if want to use some command line command they provide. For using in some node.js application, prefer to install them locally. If you still want to use the globally installed modules inside the application, you should use the link command (though I'm not sure if it works in a Windows environment).
Bower is another thing completely. Looking at the api documentation, you will see that there is no option to install modules globally (which makes sense, as Bower is intended for front-end dependencies).
You could change the default folder using the directory parameter of your .bowerrc file (see the documentation). This way you would be able to set all projects to use the same folder, but notice that's not the way it's intended to use and you would need to set it in all projects.
npm config set registry <registry url>
once this command is run, check in ~/.npmrc, it must show your changes.
I'm working with NodeJS in a small standalone isolated environment, as such commands like npm install -g can't reach out to the internet for dependencies. To "workaround" this constraint, I'm doing installs on a regular system and just air-gaping the pieces over.
Any given module (and all its dependencies) lives in /usr/local/lib/node_modules/XXXXX, and if I'm actually in that directory and enter node cli.js, it works.
However, back on the main system invoking module XXXXX by name from the command line runs that particular module. The isolated system does not, and I'm trying to find that last little step of how npm is wiring things up.
What's the pedantic methodology once one's this far to teach npm (or node) of the new command?
I'm willing to resort to hacks or aliases if absolutely necessary, but I'd like to do it the npm way.
Unfortunately, I'm not at liberty to set up a CouchDB or such and run a mirrored repository — I'm working in a tight footprint that's trying to keep things small and sleek.
Supposed I want to write a module for Node.js that shall be installed globally. I do not want to write any C++ (or something else), but plain Node.js code.
Basically, this is very easy. Just write the module, and install it using npm install -g.
Now, most globally installed modules provide the possibility to call them directly, e.g. you can type express at your command prompt and run the globally installed application bootstrapper of Express.
Now my question is: How do I achieve this?
If I simply install a module globally, this does not make one of the files available as an executable, or puts that file onto the PATH.
What steps do I need to do in order to achieve this?
So my question is basically: What steps need to be done to create globally available executable out of a "normal" Node.js module?
You need to write an executable file. This is what will be executed when a user types your command. Here's an example taken from JSHint:
#!/usr/bin/env node
require("./../src/cli/cli.js").interpret(process.argv);
Convention says to place this file in a bin directory in the root of your project. You then just need to update your package.json file to tell it where to find your executable:
{
"bin": {
"jshint": "./bin/jshint"
}
}
In this case, the executable file can be run from the terminal with the jshint command. When it runs, it simply requires another file and calls a method in it, passing through any command line arguments.