Node's Ecosystem

Learning Centre
Bevry DocPad GitHub
Search…
Welcome
Install Node.js
Hands on with Node.js
Node's Ecosystem
Core
Node was created by Ryan Dahl. Then it was maintained by Joyent. Now it is maintained by the Node.js Foundation. Node is open-source and located on github. Anyone can contribute to shape its future.​
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.
Programs
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:
package.json
1
{
2
  "name": "my-program",
3
  "version": "1.0.0",
4
  "description": "program description",
5
  "homepage": "http://programs-website.com",
6
  "keywords": [
7
    "one",
8
    "two",
9
    "three"
10
  ],
11
  "author": "Bevry Pty Ltd <[email protected]> (http://bevry.me)",
12
  "maintainers": [
13
    "Benjamin Lupton <[email protected]> (http://balupton.com)"
14
  ],
15
  "contributors": [
16
    "Benjamin Lupton <[email protected]> (http://balupton.com)"
17
  ],
18
  "bugs": {
19
    "url": "http://programs-issue-tracker.com"
20
  },
21
  "repository": {
22
    "type": "git",
23
    "url": "http://programs-repository.git"
24
  },
25
  "engines": {
26
    "node": ">=0.6.0",
27
    "npm": ">=1.1.0"
28
  },
29
  "dependencies": {
30
    "connect": "2.6.x",
31
    "express": "3.0.x",
32
    "socket.io": "0.9.x"
33
  },
34
  "devDependencies": {
35
    "coffee-script": "1.4.x"
36
  },
37
  "directories": {
38
    "lib": "./lib"
39
  },
40
  "bin": {
41
    "program": "./bin/program"
42
  },
43
  "scripts": {
44
    "test": "node ./test/everything.test.js"
45
  },
46
  "main": "./main.js"
47
}
Copied!
A lot is defined here; the best way to discover their meanings is by referring to specification on the npmjs website.​
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 runs npm publish.
Modules
Modules are just like programs, except the author has decided to publish them to the world using npm - whose website includes a directory of all the published modules for you surf and discover.
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>
Modules will generally abide by semantic versioning rules, npm also supports semver ranges, this allows you to increase compatability by doing:
1.
{ "dependencies": {"some-dependency": "~1.2.3"} } which will accepted all v1.2 versions of that dependency that are v1.2.3 or higher
2.
{ "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.
If you are building a mission critical app, you can use shrinkwrap and/or bundled dependencies to help guarantee stability, even while using version ranges.
Discovering Modules
The npm website is the best place for discovering all the modules. Good modules generally have:
1.
Modules that already use it (called dependents) - found on the npm website in the right sidebar
2.
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.
Hands on with Node.js - Previous
What is Node.js
Next - Hands on with Node.js
Simple Servers
Last modified 2yr ago
Copy link
Contents