06 Apr 2014
Here are some quick tips to help you be more productive with npm.
Use this to see any module dependencies that are out of date. This can get kind
of ugly though so specify the depth to see only your outdated dependencies.
The link command creates a symbolic link to a module on your machine. Use this
to easily consume modules that you are working on. You can also link a global
module to your path when working on a command line module.
To use a local module, change to the directory of your project and run
$ npm link /path/to/module
You will then have access to that module from your project.
Use npm version to update the version of your module. This will update the
package.json version for the module and commit the change.
Use this ignore file to prevent your test sources from being published along
with your module. This works the same way as
# do not publish unnecessary files:
npm has some helpful shortcuts to make your life easier, here are some common
$ npm i <module> # short for npm install
$ npm i <module> -S # short for npm install --save
$ npm i <module> -D # short for npm install --save-dev
$ npm i <module> -g # short for npm install --global
$ npm r <module> # short for npm uninstall
17 Jan 2014
I talked about using make with node, but
this is specific to the JSHint configuration/target for make.
One of my favorite things about JSHint is how easy it is to configure the
rules. I have an rc file that I typically use (this changes a little when I'm
This goes in the root of the directory alongside the Makefile.
This has the
expr relaxing options turned on because I'm that
kind of person. Also included are the globals for Mocha.
The default JSHint reporter is lacking. Mostly in the fact that, if the lint
succeeds, there is not output, but also because it's just plain ugly and not
too easy to read. Fortunately, our friend
Sindre solved this problem with
JSHint-Stylish which formats
errors in a much better way and also lets you know when the lint succeeded.
The actual lint target in make
--reporter node_modules/jshint-stylish/stylish.js \
This relies on all of the source files being declared in a variable named
SRC. I like to do this just to make sure that the target is clean and pretty.
You can use
$(wilcard dir/*.js) to ensure that all files in a directory are
included in the lint.
There is no need to specify the rc file because JSHint checks the current
working directory for a
.jshintrc to use.
07 Jan 2014
You'll need the following (or make sure they are up to date):
Log into Modulus CLI then create a token:
$ modulus token create
Welcome to Modulus
You are logged in as fiveisprime
[✓] Token: 4e287c37-2e7d-416f-bf53-dab7d564c262
The Modulus CLI checks for the
MODULUS_TOKEN environment variable that is used
to run commands without running the login command first. Obviously, you won't
want this token to be visible in your
.travis.yml configuration file so you'll
need to encrypt it using the travis CLI.
$ travis encrypt MODULUS_TOKEN=4e287c37-2e7d-416f-bf53-dab7d564c262
This will output a secure variable -- something like
secure: "...". If you
already have a
.travis.yml file, you can include the
--add option to add
the variable to your configuration file automatically.
If you don't already have a configuration file, create a file named
.travis.yml in the root of your repository and paste in the following:
# Include which versions of node to test against here.
# Replace the next line with the output from travis.
- secure: "..."
- npm install -g modulus
- modulus deploy -p "my project name"
env:global:secure property which is where you will copy your
encrypted token from travis.
This configuration will run the
npm test script against node versions 0.8.x
and 0.10.x then, if successful, install the Modulus CLI and deploy your