Node.JS: Error Cannot find module [SOLVED]

Even though I have installed my npm package globally, I receive the following error :

Error: Cannot find module 'color'
 at Function.Module._resolveFilename (module.js:338:15)
 at Function.Module._load (module.js:280:25)
 at Module.require (module.js:364:17)
 at require (module.js:380:17)
 at repl:1:2
 at REPLServer.self.eval (repl.js:110:21)
 at Interface. (repl.js:239:12)
 at Interface.emit (events.js:95:17)
 at Interface._onLine (readline.js:202:10)
 at Interface._line (readline.js:531:8)

I did have some assumptions here that once the npm package is installed with “-g” or “–global” switch, it will find this package automatically. But after the struggle of installing, uninstalling, reinstalling, clearing cache locally, it did not solve my problem.

Overall, I knew how how the process of searching a module goes with “npm install” command. What I did not know that there is a variable called $NODE_PATH, which needs to have a right value.

For anyone else running into this problem, you need to check the value of $NODE_PATH variable with this command

root$ echo $NODE_PATH

If it is empty then this article may give you the solution that you are looking for.

What should be the value of this variable?

Lets find out the appropriate value for $NODE_PATH

Type in the following command line:

root$ which npm

This command will give you the path where npm is installed and running from.

In my case it is “/usr/local/bin/npm” and now note down the path.

Navigate to the /usr/local with the help of finder/ explorer. You will find the folder called “lib” and within that “lib” folder you will be able to see node_modules folder, which is your global level module folder. This is the place where all your global packages are installed.

All you have to do now is set the NODE_PATH with the path that you have found for node_modules.

example:

export NODE_PATH=’module path’

In my case it is /usr/local/lib/node_modules

export NODE_PATH='/usr/local/lib/node_modules'

NOTE: There is an another and probably, an easy way to find your global node_modules folder is by installing any package with –verbose flag.
For example, you can run

root$ npm install –global –verbose promised-io

It will install the npm package and it will give you the location where promised-io is installed. You can just pick the location and set the same in $NODE_PATH.

Here is an another twist.

Now everything will work fine within the session of current terminal. If you restart the terminal, and then echo $NODE_PATH, it will return and empty response.

What is the permanent solution?

You need to make the above export statement as a part of your .bash_profile file so that it is set as soon as you are logged in.

STEPS:

  1. Close all your terminal windows and open once again:
  2. type in root$: vi ~/.bash_rc file and add this line:export NODE_PATH=’module path’

    In my case:

    export NODE_PATH=’/usr/local/lib/node_modules’

  3. type root$: vi ~/.bash_profile and add this line:source ~/.bash_profile
  4. Close all terminal windows and try again with “echo $NODE_PATH” into new command window.

    If it still does not work then for the first time, just type in this command with the same window.

    source ~/.bash_profile

 

Know more about  $NODE_PATH

(Reference: https://nodejs.org/api/modules.html#modules_loading_from_the_global_folders )

Loading from the global folders

If the NODE_PATH environment variable is set to a colon-delimited list of absolute paths, then Node.js will search those paths for modules if they are not found elsewhere. (Note: On Windows, NODE_PATH is delimited by semicolons instead of colons.)

NODE_PATH was originally created to support loading modules from varying paths before the current module resolution algorithm was frozen.

NODE_PATH is still supported, but is less necessary now that the Node.js ecosystem has settled on a convention for locating dependent modules. Sometimes deployments that rely on NODE_PATH show surprising behavior when people are unaware that NODE_PATH must be set. Sometimes a module’s dependencies change, causing a different version (or even a different module) to be loaded as the NODE_PATHis searched.

Additionally, Node.js will search in the following locations:

  • 1: $HOME/.node_modules
  • 2: $HOME/.node_libraries
  • 3: $PREFIX/lib/node

Where $HOME is the user’s home directory, and $PREFIX is Node.js’s configured node_prefix.

These are mostly for historic reasons. You are highly encouraged to place your dependencies locally innode_modules folders. They will be loaded faster, and more reliably.

Demystifying NodeJs “exports” keyword

Introduction

There has been a little confusion, in my mind, about using module.exports or exports in my nodejs coding. I have seen some code on github or otherwise, many of us are using the following exports statements:

  • exports.fn = function() { … }
  • module.exports.fn = function() ( … )
  • module.exports = exports = myobject.

Then my mind wonder:

  • What is the difference between “module.exports” and “exports” ?
  • Why Nodejs has introduced module.exports as well as exports ?
  • What does it means by module.exports = exports = object ?
  • What I prefer?

In this post, I will try to answer the above four questions. First, we will give a practical sense to exports.fn, module.exports.fn & module.exports = exports statement.

So let us start our journey with codebased

Explanation

Simplified Version

The “exports” is simply a global reference to module.exports, which initially is defined as an empty object that you can add properties to. Thus, exports.fn is shorthand for module.exports.fn.

As a result, if “exports” is set to anything else, it breaks the reference between module.exports and “exports”. Because module.exports is what really gets exported, “exports” will no longer work as expected. Thus, to ensure it is referencing to the same memory location, many of us reassign the value to module.exports as well as exports at the same time.

module.exports = exports = myobject

Detailed Version

In this sesion, I will try to demonstrate the same with code.

I pre-assumed that your nodejs is available through the command prompt. If you need an installation help, please click here.

Let us create a new file in node.

-------- laptop.js -----------
 
 exports.start = function(who) {
  console.log(who + ' instance has started this laptop');
 }

// calling a method within laptop.js
module.exports.start('module.exports');

Now create a new file that will import laptop file.

-------- app.js -----------
 
 require('./laptop.js')

Call app.js from the command prompt.

c:\ node app.js

Output
-----------------------------------------------

module.exports instance has started this laptop.

As you can see that even though we have defined a function with “exports” variable, it is available through “module.exports”.

Similarly if you do it opposite that will work too.

-------- laptop.js -----------
 
 module.exports.start = function(who) {
  console.log(who + ' instance has started this laptop');
 }

exports.start('exports');

Call app.js from the command prompt.

c:\ node app.js

Output
-----------------------------------------------

exports instance has started this laptop.

Now let see what happens here:

-------- laptop.js -----------
module.exports.start = function(who) {
 console.log(who + ' instance has started this laptop');
 }
 exports.start = function(who) {
 console.log(who + ' instance has started this laptop');
 }

exports.start('exports');
module.exports.start('module.exports');

Any guess what will be outcome?

Yes, the module.exports.start has overridden by the export.start.

Call app.js from the command prompt.

c:\ node app.js
 Output
 -----------------------------------------------

 exports instance has started this laptop.
 exports instance has started this laptop.

It is clear that “exports” is an alias to “module.exports”.

We will now try to recall our  questions one by one and answer those:

1. What is the difference between exports vs module.exports ?

Node.js does not allow you to override “exports” variable with any another memory address. However you can attach N number of properties to “exports”. Thus anything that assign directly to “exports” will not be available when it is exported.

You can export anything through “module.exports” but not with”exports” keyword.

You can do this:

module.exports = function() {
 }

or

module.exports = myobject;

Basically, anything that you have exported through module.exports will be available at app.js above. However, you cannot do like this in your laptop.js and then consider it is available in app.js.

exports = function () {
 }

or

exports = myobject;

It is clear now that you can export anything (function, object, constant value) through “module.exports” but not with “exports”.

Sounds crazy? Yes it is.

2. Why they have introduced module.exports as well as exports ?

I think the main reason could be to reduce number of characters to type?

3. What does it means by module.exports = exports = object ?

Many of us set module.exports and exports at the same time, to ensure exports isn’t referencing the prior exported object. By setting both you use exports as a shorthand and avoid potential bugs later on down the road (within same file).

Here is a piece of code to make it:

------ laptop.js ------

exports = "exports";
module.exports = "module.exports";

console.log(exports);
console.log(module.exports);

Call app.js from the command prompt.

c:\ node app.js
 Output
 -----------------------------------------------
exports
module.exports

Because they are pointing to a different location and by any chance the module has decided to use “exports” (not “module.exports” variable) value after it is set it will not be in sync.

Thus, to make it in sync. it is advisable that the “exports” variable has been set by anything you would want to define a rule that whenever we set module.exports with any value set the same value to exports in the same line.

Here is an example:

------ laptop.js ------
 
exports = 'i am value ';
module.exports = exports = function() {
   console.log('function is called.');
 }
console.log(typeof exports)
-------- app.js --------

var laptop = require('./lib/laptop.js');
laptop();

 

Call app.js from the command prompt.

c:\ node app.js
 Output
 -----------------------------------------------
function
function is called.

You can see in the output that because “exports” as well as “module.exports” are set to a function the output of “typeof” statement is “function”. If you don’t assign a function to exports then the typeof statement will produce “string”.

Thus, to remove any potential bugs we decide to set exports as well as “module.exports” at the same time.

Now this discussion is coming to an end with the last question i.e.

What I prefer?

Personally, I prefer to export a constructor function that can be used create an instance of a module.

example:

------ laptop.js ------

var laptop = function() {}
laptop.prototype.start = function() {};
laptop.prototype.stop = function() {};
laptop.prototype.suspend = function() {};
module.exports = exports = laptop;
 ------ app.js ------
var laptop = require('./laptop')
var mac = new laptop();
var win = new laptop();

However, if I want to give a singleton object then I replace the following line in laptop.js

------ laptop.js ------

module.exports = exports = new laptop();

and in app.js

 ------ app.js ------

var mac = require('./laptop');
mac.start();

Conclusion

  • We understand now that the exports is an alias to module.exports that can shorthand your writing in module development.
  • It is recommended that we point exports alias to module.exports value. Thus you should set exports whenever you are setting module.exports.
  • Since my background is .net, I recommend to export a class (constructor function) or an object.

– Happy coding!

npm –save or –save-dev. Which one to use?

Introduction

If you have ever worked in NodeJs, you must have install one or two packages through “npm install <package>” command.  By running this command, the nodeJs will install this package on your working directory, under node_modules.

To save this packages as your dependencies, under package.json, you have two choices:

  • –save-dev
  • –save
What is package.json? 

All npm packages contain a file, usually in the project root, called package.json - this file holds various metadata relevant to the project. This file is used to give information to npm that allows it to identify the project as well as handle the project's dependencies. It can also contain other metadata such as a project description, the version of the project in a particular distribution, license information and et al.

Let us understand the difference that it can make.

Detail

Say you have a package.json within your root folder of your project.

If you don't have one then create a package file using npm init command.

My package.json looks like this:

{
 "name": "TMSPA",
 "version": "1.0.0",
 "description": "Single page application for TM",
 "main": "index.html",
 "scripts": {
 "test": "echo \"Error: no test specified\" && exit 1"
 },
 "repository": {
 "type": "git",
 "url": "https://github.com/codebased/android-test.git"
 },
 "author": "Am",
 "license": "ISC",
 "bugs": {
 "url": "https://github.com/codebased/android-test/issues"
 },
 "homepage": "https://github.com/codebased/android-test"
}

Now I want to install some dependencies.

Before I install one, I need to search for the package name. If you know the package that you want to install thats good. Otherwise, you can use npm search command:

npm search bootstrap

or try one of the following search tools:

Once you have identified the right package that you want to install, you can use the mentioned command i.e. npm install <package name>.

Here you have two, actually three, options.

1. use –save-dev
e.g. npm install should --save-dev

You will use this option when you want to download a package for developers , such as grunt, gulp, then use this option. Thus, when you are distributing your code to production, these dependencies will not be available.

As an example, let say, you want to use grunt as your task runner. This package is required for development purpose. Thus, you should use –save-dev here.

npm install grunt --save-dev

The above command will save grunt dependency under devDependencies section of your package.json, shown below:

{
 "name": "TMSPA",
 "version": "1.0.0",
 "description": "Single page application for TM",
 "main": "index.html",
 "scripts": {
..
 "author": "Codebased",
..
..,
 "devDependencies": {
 "gulp": "^3.8.11"
 }
}
2. Use –save flag

You will use this option when you want to save a package dependency for distribution. Item such as angularjs, or any other module that is is required at run time by your program, you will use –save switch.

npm install angularjs --save

Now my package.json looks like this:

{
 "name": "TMSPA",
 "version": "1.0.0",
 "description": "Single page application for TM",
...,
 "dependencies":{
 "angularjs": "^1.4."
 },
 "devDependencies": {
 "gulp": "^3.8.11"
 }
}



3. Use nothing

If you call npm install command without any flag then it will install package. However, there is no way the package.json will be updated with your dependencies.

This option is not recommended because there is no way others will get to know about the dependencies that your module has.

Conclusion

In conclusion, we understand that the –save-dev, and –save flags are used for limiting the scope of your dependencies.

 

Nodejs tools

nodemon:

By default node process needs to be restarted for picking any change in your JS file. Thus, every time there is a change, you will need to stop node process and start it again.

You can automate this task by using nodemon npm package. This package will monitor any changes and it restart your application

npm install nodemon -g

Once the installation is completed you can start your node process by this command:

nodemon app.js

That’s it!

Now, as soon you will do some changes in your app.js, it will restart the process for you.

Node-inspector

Another most important tool that you would like to use during your development is node-inspector. This tool will allow you to debug your node development.

Install this tool by this command:

npm install node-inspector -g

Then call this package with this command:

node-inspector app.js --debug

Another way to run your process in debug is:

node-debug app.js

Using Node-Inspector and Nodemon together:

You can use both packages together by using this command:

node-inspector & nodemon --debug app.js