We Keep Coding

Must i specify dependencies in package json file

I just recently heard of the package.json file but all my small projects have always worked without it.
I've installed many npm modules globally and always use var x = require("express");"just for example" without even initializing the package.json and putting express as a dependency.
Is it really important

First of all, I strongly doubt require("express") will work out of the box without having the express package installed in your project's node_modules folder, but just globally. There are ways to accomplish this, though.
But even if you accomplished to require packages from the global installation folder, what happens if you have multiple packages requiring different versions of the same package? There may be breaking changes between major versions of packages. So if you install a new version of package xy globally, older projects of yours expecting a different version of package xy may stop working.
On just your local machine, you can achieve all that, still without a package.json though.
The main purpose of the package.json comes clear, when you want to share your project with other people. Aside from some basic information (like a package name and some description), it will also list the dependencies which need to be installed for the project to be runable. While the necessary dependencies may exist on your machine, how will you make sure, they are also installed on a different machine without having them listed somewhere? And the place for listing the dependencies of a package is -- surprise surprise --- the package.json file ...

They are global, not in your project so when you do the deploy, you will must have to install all global for each server.
Yuu can install packages-cli global, but project dependencies ( also dev on dev dependencies) is better have its own package.json so you can deploy.
Also if you share your project, how someone will know what packages is needed.
The better is to have for each project its own package.json on its root folder, even if you always use the same libs.

Globally installed NPM packages not recognised

I had a system crash. While trying to fix it, I deleted a few files and (I may be wrong here), I deleted ~/.profile file among them.
After system restore, my globally installed npm packages are not working.
I uninstalled npm and node and installed the latest version of nodejs 16.x, and then reinstalled globally required npm packages, however, they are still not working. Somewhere the environment variables (in .profile file?) have gone missing.
How can I get the globally installed packages to run?

You are missing the path to the globally installed npm modules in your PATH. There are multiple fixes described on this page, one of which:
Open or create a ~/.profile file and add this line:
export PATH=~/.npm-global/bin:$PATH
Back on the command line, update your system variables:
source ~/.profile

How can I test local installation of an NPM package I've published?

I recently published a package to NPM. The package works well on my own computer, where I wrote the code, but upon npm install on a coworkers machine, I start receiving errors.
What is the best way to go about installing and testing my package on my own computer? I could trace through the errors on my coworkers computer, but I assume there is a way I can do this on my own machine.

You don't have to install it on your own computer first if you want to test it, you could write unit tests instead, since you have to require the package if you do (just like an npm install).
Check the package.json to see if all needed modules are listed under dependencies. (Delete the node_modules folder, run npm install and see what errors are given)
If there is a file called .npmrc, check what files/folders it lists to make sure it's not excluding important files from NPM.
Make sure your module has a module.exports object, to be able to access the objects/functions
If this all didn't help, it might be a more specific problem and a GitHub link would help us more

Uncaught Error: Module did not self-register

I try to use node-vlc with nw.js (v0.12.0-alpha2). When i launch my app without nw.js it works, but when i launch it with nw.js i got an error:
Uncaught Error: Module did not self-register.", source: /home/alexis/Bureau/dev/jukebox/node_modules/vlc/node_modules/ffi/node_modules/bindings/bindings.js (84)
I tried some commands with nw-gyp but it couldn't help me.
I am on Ubuntu 14, 64-bit.

If you've upgraded node then npm rebuild might fix this for you

For me:
rm -r node_modules then
npm install

I had a similar issue with another product and my fix was to change the version of node I was using. I was using 0.12.0 and changed back to 0.10.26.
Personally, I use NVM to handle node version changing. With NVM installed it's as simple as running
nvm use 0.10.26
Or setting the default version to 0.10.26
nvm alias default 0.10.26
Hopefully this helps you out - our issues came from different products but the solution may be the same.

I had similar problem.
/Users/user/NodeAddons/bridge/node_modules/bindings/bindings.js:83
Error: Module did not self-register.
In my case I was doing a C/C++ Add-on, and I had forgotten to export the add-on, in my main.cc was missing the code below:
void Init(v8::Handle<v8::Object> exports) {
NODE_SET_METHOD(exports, "method", method);
}
NODE_MODULE(method, Init);
Hope this helps others!
Thanks :)

I've add the same issue because I installed to modules as sudo...
Removing the node modules folder and reinstalling as normal user fixed it.

For me npm rebuild or npm update didn't work. I had to remove the node_modules folder and run npm install to install them again.

I once had this problem when creating a multi-file c++ addon. In my binding.gyp file I had:
"sources": ["src/*.cc", "src/*.h" ]
And my project contained several *.cc files. However, the NODE_MODULE() macro was called only on one file which imported the rest of the files. But node expects that it is called on the frist *.cc file listed in sources. So I had to change sources to explicitly add that file to the beginning

For me, running npm update worked

I was getting an internal error: Module did not self-register.
Deleted the node_modules folder
ran npm install
It worked just fine.

I had this error with Snappy. Was using Node 11. Checked Snappy's NPM page https://www.npmjs.com/package/snappy where they listed which versions of node they supported.
Deleting node_modules folder rm -rf node_modules and then reinstalling using the correct version of Node resolved it.
One of the versions they supported on Linux at the time of this writing was Node version 12.
nvm deactivate 11
nvm uninstall 11
nvm install 12
nvm use 12
Problem solved
Another cause of this problem: if you're using pm2, then after upgrading node you may need to reinstall pm2. Test whether pm2 is the issue by running your app
without pm2 node server.js
then with pm2: pm2 start server.js.
Proper way to update PM2 after updating Node.js

I had this same issue with 0.12 and io.js 1.3.0, reverting to Node.js 0.10 fixed the issue.

Rebuild your C++ add-ons.
Did you encounter something like this?
Module did not self-register: '…\node_modules\#u4\opencv4nodejs\build\Release\opencv4nodejs.node
It’s likely that you have just updated your Node.js. Once you updated your Node.js, you need to rebuild your C++ add-ons, Node.js packages written in C++.
Why
When you build Node.js’ C++ add-ons, they get compiled into require-able .node files and linked to the currently installed Node.js ABI library, which is not compatible with other versions of it. Your packages were built only compatible with the specific version of Node.js.
How
Firstly, try npm rebuild. If your C++-add-on-based packages have a build script, it’ll do. If it doesn’t, you need to manually build your C++ native add-on packages. Do again what you did when you were installing such packages. Refer to the building instructions in the packages’ documentations to rebuild them. Or try reinstalling (npm install) them.

I had the same problem. My script that was referencing a global reference script had an invalid reference. I took off that invalid reference and the error was gone. My error message had no indication of that particular invalid reference which made it harder to debug. But 'Uncaught Error: Module did not self-register' was the message I was getting.
This also happen in my other project. For some reason, it wouldn't recognize the reference path if one of the characters are uppercase. Even thought, the upper-casing was the correct spelling of the path.

I had this issue while setting up my Cypress project.
I found out the issue was caused because Cypress uses node from its bundle version by default (which was version 8.0 in my case) , whilst the package I wanted to use required the node version to be 10 or higher.
I did have node 12.0 installed on my machine but since cypress was not using that I had to add the line shown below in the settings file (cypress.json) to set the value for 'nodeVersion' to 'system', to tell cypress explicitly to use the node version installed on my machine.
Add this line to your settings file:
**"nodeVersion": "system"**

Why do we need to install gulp globally and locally?

2 manuals about gulp say that I need to install gulp first globally (with -g flag) and then one more time locally. Why do I need this?

When installing a tool globally it's to be used by a user as a command line utility anywhere, including outside of node projects. Global installs for a node project are bad because they make deployment more difficult.
npm 5.2+
The npx utility bundled with npm 5.2 solves this problem. With it you can invoke locally installed utilities like globally installed utilities (but you must begin the command with npx). For example, if you want to invoke a locally installed eslint, you can do:
npx eslint .
npm < 5.2
When used in a script field of your package.json, npm searches node_modules for the tool as well as globally installed modules, so the local install is sufficient.
So, if you are happy with (in your package.json):
"devDependencies": {
"gulp": "3.5.2"
}
"scripts": {
"test": "gulp test"
}
etc. and running with npm run test then you shouldn't need the global install at all.
Both methods are useful for getting people set up with your project since sudo isn't needed. It also means that gulp will be updated when the version is bumped in the package.json, so everyone will be using the same version of gulp when developing with your project.
Addendum:
It appears that gulp has some unusual behaviour when used globally. When used as a global install, gulp looks for a locally installed gulp to pass control to. Therefore a gulp global install requires a gulp local install to work. The answer above still stands though. Local installs are always preferable to global installs.

TLDR; Here's why:
The reason this works is because gulp tries to run your gulpfile.js using your locally installed version of gulp, see here. Hence the reason for a global and local install of gulp.
Essentially, when you install gulp locally the script isn't in your PATH and so you can't just type gulp and expect the shell to find the command. By installing it globally the gulp script gets into your PATH because the global node/bin/ directory is most likely on your path.
To respect your local dependencies though, gulp will use your locally installed version of itself to run the gulpfile.js.

You can link the globally installed gulp locally with
npm link gulp

The question "Why do we need to install gulp globally and locally?" can be broken down into the following two questions:
Why do I need to install gulp locally if I've already installed it globally?
Why do I need to install gulp globally if I've already installed it locally?
Several others have provided excellent answers to theses questions in isolation, but I thought it would be beneficial to consolidate the information in a unified answer.
Why do I need to install gulp locally if I've already installed it globally?
The rationale for installing gulp locally is comprised of several reasons:
Including the dependencies of your project locally ensures the version of gulp (or other dependencies) used is the originally intended version.
Node doesn't consider global modules by default when using require() (which you need to include gulp within your script). Ultimately, this is because the path to the global modules isn't added to NODE_PATH by default.
According to the Node development team, local modules load faster. I can't say why this is, but this would seem to be more relevant to node's use in production (i.e. run-time dependencies) than in development (i.e. dev dependencies). I suppose this is a legitimate reason as some may care about whatever minor speed advantage is gained loading local vs. global modules, but feel free to raise your eyebrow at this reason.
Why do I need to install gulp globally if I've already installed it locally?
The rationale for installing gulp globally is really just the convenience of having the gulp executable automatically found within your system path.
To avoid installing locally you can use npm link [package], but the link command as well as the install --global command doesn't seem to support the --save-dev option which means there doesn't appear to be an easy way to install gulp globally and then easily add whatever version that is to your local package.json file.
Ultimately, I believe it makes more sense to have the option of using global modules to avoid having to duplicate the installation of common tools across all your projects, especially in the case of development tools such as grunt, gulp, jshint, etc. Unfortunately it seems you end up fighting the tools a bit when you go against the grain.

Technically you don't need to install it globally if the node_modules folder in your local installation is in your PATH. Generally this isn't a good idea.
Alternatively if npm test references gulp then you can just type npm test and it'll run the local gulp.
I've never installed gulp globally -- I think it's bad form.

I'm not sure if our problem was directly related with installing gulp only locally. But we had to install a bunch of dependencies ourself. This lead to a "huge" package.json and we are not sure if it is really a great idea to install gulp only locally. We had to do so because of our build environment. But I wouldn't recommend installing gulp not globally if it isn't absolutely necessary. We faced similar problems as described in the following blog-post
None of these problems arise for any of our developers on their local machines because they all installed gulp globally. On the build system we had the described problems. If someone is interested I could dive deeper into this issue. But right now I just wanted to mention that it isn't an easy path to install gulp only locally.

Just because I haven't seen it here, if you are on MacOS or Linux, I suggest you add this to your PATH (in your bashrc etc):
node_modules/.bin
With this relative path entry, if you are sitting in the root folder of any node project, you can run any command line tool (eslint, gulp, etc. etc.) without worrying about "global installs" or npm run etc.
Once I did this, I've never installed a module globally.