Node's Ecosystem
Last updated
Was this helpful?
Last updated
Was this helpful?
Node was created by . Then it was maintained by . Now it is maintained by the . Node is open-source and .
The mission of the core is to be as lightweight as possible. If a module can do something, then it won't make it into the core.
Executing node code is as easy as running node your-node-file
. To make use of other modules, you will want to write a package.json
file in the root directory of your program. This file is used to define your application, including information such as its name, description, environments it can run under, and any modules it is dependent on. If you decide to publish your program to the world (making it a module others can use) then you will require a package.json
file.
A typical package.json
will look like this:
If you are writing a program that you never want to be released to the outside world, you will want to add
"private": true
as well. This will tell npm to never publish your program even if someone accidentally runsnpm publish
.
To publish your program as a module, run npm publish
in your program's directory
To use a module in your program, you first install it to your program using npm install <module-name>
, then you can use it in your code by doing var theModule = require('module-name');
To install a module globally (so you can utilise its executables if it has any) you will use npm install -g <module-name>
{ "dependencies": {"some-dependency": "~1.2.3"} }
which will accepted all v1.2 versions of that dependency that are v1.2.3 or higher
{ "dependencies": {"some-dependency": "^1.2.3"} }
which will accepted all v1 versions of that dependency that are v1.2.3 or higher
Both of these are better than just doing "1.2.3"
directly, as it decreases maintenance when new versions come out which are often compatible depending on the module authors practices.
Never specify a range that has no upper limit, such as >=1
or *
as soon enough, the module will publish a breaking change that will break your app. Hence why semver exists.
Modules that already use it (called dependents) - found on the npm website in the right sidebar
Tests that guarantee it runs well — found in the source code repository of the module
Earlier than 2014, "last update" was also a factor to judge, however since 2015, node.js has minimised breaking changes allowing small modules that do a few things well to go unchanged over the years while continuing to work splendidly.
A lot is defined here;
Modules are just like programs, except the author has decided to publish them to the world using - whose website includes a directory of all the published modules for you surf and discover.
Modules will generally abide by , npm also supports semver ranges, this allows you to increase compatability by doing:
If you are building a mission critical app, you can use and/or to help guarantee stability, even while using version ranges.
The is the best place for discovering all the modules. Good modules generally have: