Related
This documentation answers my question very poorly. I didn't understand those explanations. Can someone say in simpler words? Maybe with examples if it's hard to choose simple words?
EDIT also added peerDependencies, which is closely related and might cause confusion.
Summary of important behavior differences:
dependencies are installed on both:
npm install from a directory that contains package.json
npm install $package on any other directory
devDependencies are:
also installed on npm install on a directory that contains package.json, unless you pass the --production flag (go upvote Gayan Charith's answer), or if the NODE_ENV=production environment variable is set
not installed on npm install "$package" on any other directory, unless you give it the --dev option.
are not installed transitively.
peerDependencies:
before 3.0: are always installed if missing, and raise an error if multiple incompatible versions of the dependency would be used by different dependencies.
expected to start on 3.0 (untested): give a warning if missing on npm install, and you have to solve the dependency yourself manually. When running, if the dependency is missing, you get an error (mentioned by #nextgentech) This explains it nicely: https://flaviocopes.com/npm-peer-dependencies/
in version 7 peerDependencies are automatically installed unless an upstream dependency conflict is present that cannot be automatically resolved
Transitivity (mentioned by Ben Hutchison):
dependencies are installed transitively: if A requires B, and B requires C, then C gets installed, otherwise, B could not work, and neither would A.
devDependencies is not installed transitively. E.g. we don't need to test B to test A, so B's testing dependencies can be left out.
Related options not discussed here:
bundledDependencies which is discussed on the following question: Advantages of bundledDependencies over normal dependencies in npm
optionalDependencies (mentioned by Aidan Feldman)
devDependencies
dependencies are required to run, devDependencies only to develop, e.g.: unit tests, CoffeeScript to JavaScript transpilation, minification, ...
If you are going to develop a package, you download it (e.g. via git clone), go to its root which contains package.json, and run:
npm install
Since you have the actual source, it is clear that you want to develop it, so by default, both dependencies (since you must, of course, run to develop) and devDependency dependencies are also installed.
If however, you are only an end user who just wants to install a package to use it, you will do from any directory:
npm install "$package"
In that case, you normally don't want the development dependencies, so you just get what is needed to use the package: dependencies.
If you really want to install development packages in that case, you can set the dev configuration option to true, possibly from the command line as:
npm install "$package" --dev
The option is false by default since this is a much less common case.
peerDependencies
(Tested before 3.0)
Source: https://nodejs.org/en/blog/npm/peer-dependencies/
With regular dependencies, you can have multiple versions of the dependency: it's simply installed inside the node_modules of the dependency.
E.g. if dependency1 and dependency2 both depend on dependency3 at different versions the project tree will look like:
root/node_modules/
|
+- dependency1/node_modules/
| |
| +- dependency3 v1.0/
|
|
+- dependency2/node_modules/
|
+- dependency3 v2.0/
Plugins, however, are packages that normally don't require the other package, which is called the host in this context. Instead:
plugins are required by the host
plugins offer a standard interface that the host expects to find
only the host will be called directly by the user, so there must be a single version of it.
E.g. if dependency1 and dependency2 peer depend on dependency3, the project tree will look like:
root/node_modules/
|
+- dependency1/
|
+- dependency2/
|
+- dependency3 v1.0/
This happens even though you never mention dependency3 in your package.json file.
I think this is an instance of the Inversion of Control design pattern.
A prototypical example of peer dependencies is Grunt, the host, and its plugins.
For example, on a Grunt plugin like https://github.com/gruntjs/grunt-contrib-uglify, you will see that:
grunt is a peer-dependency
the only require('grunt') is under tests/: it's not actually used by the program.
Then, when the user will use a plugin, he will implicitly require the plugin from the Gruntfile by adding a grunt.loadNpmTasks('grunt-contrib-uglify') line, but it's grunt that the user will call directly.
This would not work then if each plugin required a different Grunt version.
Manual
I think the documentation answers the question quite well, maybe you are just not familiar enough with node / other package managers. I probably only understand it because I know a bit about Ruby bundler.
The key line is:
These things will be installed when doing npm link or npm install from the root of a package and can be managed like any other npm configuration parameter. See npm-config(7) for more on the topic.
And then under npm-config(7) find dev:
Default: false
Type: Boolean
Install dev-dependencies along with packages.
If you do not want to install devDependencies you can use npm install --production
As an example, mocha would normally be a devDependency, since testing isn't necessary in production, while express would be a dependency.
dependencies
Dependencies that your project needs to run, like a library that provides functions that you call from your code.
They are installed transitively (if A depends on B depends on C, npm install on A will install B and C).
Example: lodash: your project calls some lodash functions.
devDependencies
Dependencies you only need during development or releasing, like compilers that take your code and compile it into javascript, test frameworks or documentation generators.
They are not installed transitively (if A depends on B dev-depends on C, npm install on A will install B only).
Example: grunt: your project uses grunt to build itself.
peerDependencies
Dependencies that your project hooks into, or modifies, in the parent project, usually a plugin for some other library or tool. It is just intended to be a check, making sure that the parent project (project that will depend on your project) has a dependency on the project you hook into. So if you make a plugin C that adds functionality to library B, then someone making a project A will need to have a dependency on B if they have a dependency on C.
They are not installed (unless npm < 3), they are only checked for.
Example: grunt: your project adds functionality to grunt and can only be used on projects that use grunt.
This documentation explains peer dependencies really well: https://nodejs.org/en/blog/npm/peer-dependencies/
Also, the npm documentation has been improved over time, and now has better explanations of the different types of dependencies: https://github.com/npm/cli/blob/latest/docs/content/configuring-npm/package-json.md#devdependencies
To save a package to package.json as dev dependencies:
npm install "$package" --save-dev
When you run npm install it will install both devDependencies and dependencies. To avoid install devDependencies run:
npm install --production
There are some modules and packages only necessary for development, which are not needed in production. Like it says it in the documentation:
If someone is planning on downloading and using your module in their program, then they probably don't want or need to download and build the external test or documentation framework that you use. In this case, it's best to list these additional items in a devDependencies hash.
peerDependencies didn't quite make sense for me until I read this snippet from a blog post on the topic Ciro mentioned above:
What [plugins] need is a way of expressing these “dependencies” between plugins and their host package. Some way of saying, “I only work when plugged in to version 1.2.x of my host package, so if you install me, be sure that it’s alongside a compatible host.” We call this relationship a peer dependency.
The plugin does expect a specific version of the host...
peerDependencies are for plugins, libraries that require a "host" library to perform their function, but may have been written at a time before the latest version of the host was released.
That is, if I write PluginX v1 for HostLibraryX v3 and walk away, there's no guarantee PluginX v1 will work when HostLibraryX v4 (or even HostLibraryX v3.0.1) is released.
... but the plugin doesn't depend on the host...
From the point of view of the plugin, it only adds functions to the host library. I don't really "need" the host to add a dependency to a plugin, and plugins often don't literally depend on their host. If you don't have the host, the plugin harmlessly does nothing.
This means dependencies isn't really the right concept for plugins.
Even worse, if my host was treated like a dependency, we'd end up in this situation that the same blog post mentions (edited a little to use this answer's made up host & plugin):
But now, [if we treat the contemporary version of HostLibraryX as a dependency for PluginX,] running npm install results in the unexpected dependency graph of
├── HostLibraryX#4.0.0
└─┬ PluginX#1.0.0
└── HostLibraryX#3.0.0
I’ll leave the subtle failures that come from the plugin using a different [HostLibraryX] API than the main application to your imagination.
... and the host obviously doesn't depend on the plugin...
... that's the whole point of plugins. Now if the host was nice enough to include dependency information for all of its plugins, that'd solve the problem, but that'd also introduce a huge new cultural problem: plugin management!
The whole point of plugins is that they can pair up anonymously. In a perfect world, having the host manage 'em all would be neat & tidy, but we're not going to require libraries herd cats.
If we're not hierarchically dependent, maybe we're intradependent peers...
Instead, we have the concept of being peers. Neither host nor plugin sits in the other's dependency bucket. Both live at the same level of the dependency graph.
... but this is not an automatable relationship. <<< Moneyball!!!
If I'm PluginX v1 and expect a peer of (that is, have a peerDependency of) HostLibraryX v3, I'll say so. If you've auto-upgraded to the latest HostLibraryX v4 (note that's version 4) AND have Plugin v1 installed, you need to know, right?
npm can't manage this situation for me --
"Hey, I see you're using PluginX v1! I'm automatically downgrading HostLibraryX from v4 to v3, kk?"
... or...
"Hey I see you're using PluginX v1. That expects HostLibraryX v3, which you've left in the dust during your last update. To be safe, I'm automatically uninstalling Plugin v1!!1!
How about no, npm?!
So npm doesn't. It alerts you to the situation, and lets you figure out if HostLibraryX v4 is a suitable peer for Plugin v1.
Coda
Good peerDependency management in plugins will make this concept work more intuitively in practice. From the blog post, yet again...
One piece of advice: peer dependency requirements, unlike those for regular dependencies, should be lenient. You should not lock your peer dependencies down to specific patch versions. It would be really annoying if one Chai plugin peer-depended on Chai 1.4.1, while another depended on Chai 1.5.0, simply because the authors were lazy and didn’t spend the time figuring out the actual minimum version of Chai they are compatible with.
A simple explanation that made it more clear to me is:
When you deploy your app, modules in dependencies need to be installed or your app won't work. Modules in devDependencies don't need to be installed on the production server since you're not developing on that machine.
link
I found a simple explanation.
Short Answer:
dependencies
"...are those that your project really needs to be able to work in production."
devDependencies
"...are those that you need during development."
peerDependencies
"if you want to create and publish your own library so that it can be used as a dependency"
More details in this post:
https://code-trotter.com/web/dependencies-vs-devdependencies-vs-peerdependencies
I'd like to add to the answer my view on these dependencies explanations
dependencies are used for direct usage in your codebase, things that usually end up in the production code, or chunks of code
devDependencies are used for the build process, tools that help you manage how the end code will end up, third party test modules, (ex. webpack stuff)
In short
Dependencies - npm install <package> --save-prod installs packages required by your application in production environment.
DevDependencies - npm install <package> --save-dev installs
packages required only for local development and testing
Just typing npm install installs all packages mentioned in the
package.json
so if you are working on your local computer just type npm install and continue :)
Dependencies vs dev dependencies
Dev dependencies are modules which are only required during development whereas dependencies are required at runtime. If you are deploying your application, dependencies has to be installed, or else your app simply will not work. Libraries that you call from your code that enables the program to run can be considered as dependencies.
Eg- React , React - dom
Dev dependency modules need not be installed in the production server since you are not gonna develop in that machine .compilers that covert your code to javascript , test frameworks and document generators can be considered as dev-dependencies since they are only required during development .
Eg- ESLint , Babel , webpack
#FYI,
mod-a
dev-dependents:
- mod-b
dependents:
- mod-c
mod-d
dev-dependents:
- mod-e
dependents:
- mod-a
----
npm install mod-d
installed modules:
- mod-d
- mod-a
- mod-c
----
checkout the mod-d code repository
npm install
installed modules:
- mod-a
- mod-c
- mod-e
If you are publishing to npm, then it is important that you use the correct flag for the correct modules. If it is something that your npm module needs to function, then use the "--save" flag to save the module as a dependency. If it is something that your module doesn't need to function but it is needed for testing, then use the "--save-dev" flag.
# For dependent modules
npm install dependent-module --save
# For dev-dependent modules
npm install development-module --save-dev
Dependencies
These are the packages that your package needs to run, so they will be installed when people run
npm install PACKAGE-NAME
An example would be if you used jQuery in your project. If someone doesn't have jQuery installed, then it wouldn't work. To save as a dependency, use
npm install --save
Dev-Dependencies
These are the dependencies that you use in development, but isn't needed when people are using it, so when people run npm install, it won't install them since the are not necessary. For example, if you use mocha to test, people don't need mocha to run, so npm install doesn't install it. To save as a dev dependency, use
npm install PACKAGE --save-dev
Peer Dependencies
These can be used if you want to create and publish your own library so that it can be used as a dependency. For example, if you want your package to be used as a dependency in another project, then these will also be installed when someone installs the project which has your project as a dependency. Most of the time you won't use peer dependencies.
dependencies: packages that your project/package needs to work in production.
devDependencies: packages that your project/package needs to work while development but are not needed on production (eg: testing packages)
peerDependencies: packages that your project/package needs to work in tandem with (“colaborating” with them) or as a base, useful mainly when you are developing a plugin/component to let know with which version of the “main” package your plugin/component is supposed to work with (eg: React 16)
When trying to distribute an npm package you should avoid using dependencies. Instead you need to consider adding it into peerDependencies.
Update
Most of the time dependencies are just a bunch of libraries that describes your ecosystem. Unless, you're really using a specific version of a library you should instead let the user choose whether or not to install that library and which version to choose by adding it into the peerDependencies.
dependencies are required to run, devDependencies only to develop
When using Webpack to bundle a frontend application, the distinction between dependencies and devDependencies is not so clear. For the final bundle, it doesn't matter where you place the dependencies (but it may be important for other tools). That's why the documentation seems confusing.
I found the explanation here: Do "dependencies" and "devDependencies" matter when using Webpack?
What are the differences between Yarn and NPM?
At the time of writing this question I can only find some articles on the Internet showing what's the Yarn equvalent of an NPM command like this.
Do they have the same functionalities (I know Yarn does local caching and looks like you only need to download a package once) but other than this is there any benefits for moving from NPM to Yarn?
UPDATE: March 2018 (bit late...)
Since version 5, npm
generates a 'lockfile' called package-lock.json that fixes your entire dependency tree much the same way the yarn (or any other) locking mechanism does,
A tool has been made
--save is now implied for npm i
Better network and cache usage
npm 5.7.0 further introduced the npm ci command to install dependencies more quickly in a continuous integration environment by only installing packages found in the package-lock.json (reporting an error if the package-lock.json and package.json are not synchronized).
Personally, I still use npm.
Original
I am loathe to quote directly from docs, but they do a great job of explaining why, concisely enough that I don't see how to further summarize the ideas.
Largely:
You always know you're getting the same thing on every development
machine
It paralellizes operations that npm does not, and
It makes more efficient use of the network.
It may make more efficient use of other system resources (such as RAM) as well.
What are people's production experiences with it? Who knows, it's an infant to the general public.
TL;DR from Yehuda Katz:
From the get-go, the Yarn lockfile guarantees that repeatedly running
yarn on the same repository results in the same packages.
Second, Yarn attempts to have good performance, with a cold cache, but
especially with a warm cache.
Finally, Yarn makes security a core value.
Nice blog post
“NPM vs Yarn Cheat Sheet” by Gant Laborde
Slightly longer version from the project:
Fast: Yarn caches every package it downloads so it never needs to
again. It also parallelizes operations to maximize resource
utilization so install times are faster than ever.
Reliable: Using a detailed, but concise, lockfile format, and a
deterministic algorithm for installs, Yarn is able to guarantee that
an install that worked on one system will work exactly the same way on
any other system.
Secure: Yarn uses checksums to verify the integrity of every installed
package before its code is executed.
And from the README.md:
Offline Mode: If you've installed a package before, you can install it again without any internet connection.
Deterministic: The same dependencies will be installed the same exact way across every machine regardless of install order.
Network Performance: Yarn efficiently queues up requests and avoids request waterfalls in order to maximize network utilization.
Multiple Registries: Install any package from either npm or Bower and keep your package workflow the same.
Network Resilience: A single request failing won't cause an install to fail. Requests are retried upon failure.
Flat Mode: Resolve mismatching versions of dependencies to a single version to avoid creating duplicates.
More emojis. 🐈
What is PNPM?
pnpm uses hard links and symlinks to save one version of a module only ever once on a disk. When using npm or Yarn for example, if you have 100 projects using the same version of lodash, you will have 100 copies of lodash on disk. With pnpm, lodash will be saved in a single place on the disk and a hard link will put it into the node_modules where it should be installed.
As a result, you save gigabytes of space on your disk and you have a lot faster installations! If you'd like more details about the unique node_modules structure that pnpm creates and why it works fine with the Node.js ecosystem, read this small article: Why should we use pnpm?
How to install PNPM?
npm install -g pnpm
How to install npm package using PNPM?
pnpm install -g typescript // or your desired package
Benefits of PNPM over Yarn and NPM
Here is progress-bar showing installation time taken by NPM, YARN and PNPM (shorter-bar is better)
Click for Complete check Benchmark
for more details, visit https://www.npmjs.com/package/pnpm
Trying to give a better overview for beginners.
npm has been historically (2010) the most popular package manager for JavaScript. If you want to use it for managing the dependencies of your project, you can type the following command:
npm init
This will generate a package.json file. It contains all the dependencies of the project.
Then
npm install
would create a directory node_modules and download the dependencies (that you added to the package.json file) inside it.
It will also create a package-lock.json file. This file is used to describe the tree of dependecies that was generated. It allows developpers to install exectly the same dependencies. For example, you could imagine a developper upgrading a dependency to v2 and then v3 while another one directly upgrading to v3.
npm installs dependencies in a non-deterministically way meaning the two developper could have a different node_modules directory resulting into different behaviours. **npm has suffered from bad reputation as for example
in February 2018: an issue was discovered in version 5.7.0 in which running sudo npm on Linux systems would change the ownership of system files, permanently breaking the operating system.
To resolve those problems and others, Facebook introduced a new package manager (2016): Yarn a faster, more securely, and more reliably package manager for JavaScript.
You can add Yarn to a project by typing:
yarn init
This will create a package.json file. Then, install the dependencies with:
yarn install
A folder node_modules will be generated. Yarn will also generate a file called yarn.lock. This file serve the same purpose as the package-lock.json but is instead constructed using a deterministic and reliable algorithm thus leading to consistant builds.
If you started a project with npm, you can actually migrate to Yarn easily. yarn will consume the same package.json. See Migrating from npm for more details.
However, npm has been improved with each new releases and some projects still uses npm over yarn.
The answer by #msanford covers almost everything, however, I'm missing the security (OWASP's Known Vulnerabilities) part.
Yarn
You can check them using yarn audit, however, you cannot fix them. This is still an open issue on a GitHub (https://github.com/yarnpkg/yarn/issues/7075).
npm
You can use npm audit fix, so some of them you can fix by yourself.
Both of them, i.e. npm audit & yarn audit have their own Continuous Integration tools. These are respectively https://github.com/IBM/audit-ci (used, works great!) and https://yarnpkg.com/package/audit-ci (haven't used).
npm:
The package manager for JavaScript. npm is the command-line
interface to the npm ecosystem. It is battle-tested, surprisingly
flexible, and used by hundreds of thousands of JavaScript developers
every day.
NPM generates a correct lock file whereas a Yarn lock file could be
corrupt in some cases and has to be fixed with yarn-tools
Yarn:
A new package manager for JavaScript. Yarn caches every package it
downloads so it never needs to again. It also parallelizes
operations to maximize resource utilization so install times are
faster than ever.
Yarn doesn't support login with a password (while NPM does)
When you install a package using Yarn (using yarn add packagename), it places the package on your disk. During the next install, this package will be used instead of sending an HTTP request to get the tarball from the registry.
Yarn comes with a handy license checker, which can become really powerful in case you have to check the licenses of all the modules you depend on.
If you are working on proprietary software, it does not really matter which one you use. With npm, you can use npm-shrinkwrap.js, while you can use yarn.lock with Yarn.
For more information please read the following blog
https://blog.risingstack.com/yarn-vs-npm-node-js-package-managers/
Yarn
Advantages::
Supports features like parallel installation and
Zero-Install results in better performance
More secure
Large active user community
Disadvantages::
Doesn’t work with older versions of Node.js (lower than version 5)
Problems with installing native modules
NPM
Advantages::
Ease of use, especially for developers working with older
versions.
Optimized local package installation to save hard drive space.
Disadvantages::
Security vulnerabilities are still there
Conclusion:
Is Yarn better than NPM?
In terms of speed and performance Yarn is better than NPM because it performs the parallel installation. Yarn is still more secure than NPM. However, Yarn uses more disk space than NPM.
I'm using many Node.js modules through npm package manager. Since these modules are not developed by trusted organisations, are they trustworthy?
I don't know whether the npm team is doing any security checks for each module submitted by developers.
NPM is not doing any checks whatsoever. They are just a registry.
The whole thing is built on the trust in the dev community and sharing.
Most node modules are open source and you can review their code in their repository (usually Github).
So that's the best way to 'trust' them.
Some node modules give you prebuilt native binaries, so that might be riskier in a way, but if it is popular (like ws for example) then I see no issue.
You can also check the NPM publisher user, which sometimes is a known company like Oracle.
The idea is to find the most popular npm modules. You can do this by checking the stars on each project.
Some tips:
Use npm to manage dependencies in your dev environment, but not in your deployment scripts.
Tools like npm are development tools. They’re a convenient way to download and update modules. They’re not deployment tools, have never been deployment tools, and should not be used for deployment!
Use npm shrinkwrap in the development repository and check in the result. This will lock your module versions in place, including sub-dependencies
More details here
Update - June 2019
In npm#6 security check is included.
You could run npm audit to recursively analyze your dependency trees to identify specifically what’s insecure
2016 version
You could use the nsp tool provided by Node Security Platform, which helps to audit all the modules from your package.json
npm install nsp --global
nsp check
There are a few programs, available from npm, that can run against your package.json and check for known vulnerabilities. Not perfect, but a great start. The one I have used is called nsp but there are others.
It is not much secure because these modules are not developed by any organizations like what php/apache have, However it is good technology and you can also use nsp modules to check the security issues in you node modles.
Yes ! Almost all node modules are open source so you can actually view code snippets running behind module. this might help you to build your trust on package you are willing to use in your application
Actually I don't use to much packages:
1) express
2) body & cookie-parser (sometimes I'm lazy to write middleware),
3) mongoose,
4) pug,
5) request,
6) async,
7) lodash,
8) string
all other stuff I write myself and put in "components" folder.
let's say most of people so lazy that do:
const md5 = require('md5');
let data = 'something';
data = md5(data);
but I do it with crypto (it's by default included in all nodejs versions):
const crypto = require('crypto');
let data = 'something';
data = crypto
.createHash('md5')
.update(data.toString())
.digest('hex');
I keep logic to not to use package:
1) if package is small (I always read package files if it's unknown for me package)
2) version is not above 1.0.0 (no warranty that will go further)
3) no recent iterations (commits) in repository
btw nsp check of my applications says: (+) No known vulnerabilities found
(:
I've made node-safe, which allows you to use the native macOS sandbox when using node, npm and yarn:
# Allow reading files, but only in the current folder
node --enable-sandbox --allow-read="./**" myscript.js
# Run npm with sandbox (can only write to `./node_modules` by default)
npm --enable-sandbox install got
When using the sandboxed package managers rogue dependencies are not able to compromise your system anymore through postinstall scripts and other means.
If you are installing a package that you do not trust, you can avoid this vulnerability by running
npm install --ignore-scripts
for more details check here
Here is an awesome blog which can give you clear picture blog
The setup/workflow:
Project A relies on a custom npm package in package.json.
As engineers work on Project A, they will inevitably be making changes to the custom npm package as well. This is streamlined by having them clone down both the project and custom package repos, then applying npm link.
(source: http://justjs.com/posts/npm-link-developing-your-own-npm-modules-without-tears)
The question:
Assume a developer has now finished making changes to both Project A and the custom npm package. Here are the next steps:
He or she must submit a Pull Request for the custom package and wait for it to be code reviewed and merged.
He or she must now open Pull Request for Project A, containing a bumped version number on the custom package in package.json.
This feels clunky and prone to blocking our other developers.
Does anyone have suggestions for a better workflow when building a custom npm package and a project that depends on it at the same time?
What I do is use username/repo#branch as the version in package.json. This causes npm to pull directly from my fork on GitHub, bypassing the npm registry. I tend to only do this when I cannot wait for the maintainer to publish a release to the npm registry (not that often for me).
When the maintainer publishes a release to npm then I update the version number to the new release. Also, I would not include the version number in a pull request, I would always let the maintainer(s) decide how to bump the version.
So you have project A depending on package B. First, if B is under rapid development, it does not make much sense to make A dependent on B (by listing it in package.json and 'npm install'-ing it): it'll bring you more pain than gain. Instead of this, copy B directly into the A and use it directly (without using any npm machinery).
Only when B's API gets stable enough, publish it as a separate module and depend on it npm way.
But this is not all! To keep things reasonably separated and decoupled, you should use git submodules.
https://git-scm.com/book/en/v2/Git-Tools-Submodules
This great feature of git allows you to put one git repo inside another git repo. This way, both of your projects are reasonably well decoupled; also this makes the process of publishing B as a separate unit much easier.
I've tried both approaches ( a) npm with git branch dependency vs. b) git submodules, no npm) on two separate middle-sized projects and I enjoyed the submodules way much more :)
I think one possible solution is to be more generic with the versioning in Project A's package.json.
Instead of explicitly maintaining the version number of the custom npm module dependency, we can use asterisks in the semvar statements.
Eg:
"#org/custom-node-module": "0.1.2" - requires manually changing everytime the npm package is updated.
"#org/custom-node-module": "0.*.*" - running npm install will always grab the most recent non-breaking version.
How do we or can we use node modules via npm with Meteor?
Or is that something that will be dependent on the packaging API?
Or is there a prescribed method that is recommended?
Meteor 1.3, released on March 28, 2016, gives apps full ES6 (ES2015) modules support and out of the box NPM support. Apps and packages can now load NPM modules directly and easily on the client and on the server.
If you can use 1.3, then check http://guide.meteor.com/using-packages.html#installing-npm.
For example, to use moment.js:
meteor npm install --save moment
Then in your code:
import moment from 'moment';
// this is equivalent to the standard node require:
const moment = require('moment');
If you need to use an older version of Meteor, read the rest of the answer below.
Pre-Meteor 1.3:
Since v0.6.0, Meteor integrates directly with NPM modules with the help of a 3rd party package. For example, to use a module like ws,
Run sudo npm install -g ws (or for local installs, see this)
In your sever JavaScript file,
var Websocket = Npm.require('ws');
var myws = new Websocket('url');
To use a core Node module, just make the corresponding Npm.require() call, e.g. var Readable = Npm.require('stream').Readable.
You can use any of the more than 230,000 NPM modules directly with Meteor thanks to the NPM package developed by Arunoda.
You can also define dependencies on Npm packages from smart packages - from the initial announcement of npm support:
Your smart package can now define dependencies directly, by adding a call to Npm.depends in package.js:
Npm.depends({
"awssum": "0.12.2",
"underscore.string": "2.3.1"
});
All of this works well with hot code reload, just like the rest of Meteor. When you make changes, the bundler will automatically download missing npm packages and re-pin its dependencies.
To use an NPM module within server code, use Npm.require as you would normally use plain require. Notably, __meteor_bootstrap__.require has been eliminated and all of its uses have been converted to Npm.require.
There is a small example of using an NPM module in your application.
Note that this answer applies to versions of Meteor prior to 0.6.0, which was released in April 2013 and added direct npm integration
Install modules as you normally would through npm and then use
var require = __meteor_bootstrap__.require,
pd = require("pd"),
after = require("after") // etc
Load any modules you want
I did a complete write-up on this on Meteorpedia:
http://www.meteorpedia.com/read/npm
The article covers how to use npm in both your app and/or packages, and common patterns for wrapping regular callbacks and event emmitter callbacks to work properly in Meteor and Fibers, and include's references to Arunoda's async-utilities and additional resources.
You could use the Meteor Npm package
meteor add meteorhacks:npm
Then create a packages.json file in your project's root directory with the NPM module's info.
{
"redis": "0.8.2",
"github": "0.1.8"
}
Then as simple as (server side)
var github = Meteor.npmRequire("github");
var redis = Meteor.npmRequire("redis");
So you just use Meteor.npmRequire instead of require
I wrote a Gist on how to do this as of Meteor 0.6.5, How to add Node.js npms to your Meteor.js project.
I am using such a script which nicely install all Node.js dependencies. It behaves similar to the official support in the Meteor engine branch (it installs dependencies at runtime), but it also supports installing from Git repositories and similar goodies.