Tag Archives: tricks

npmoffline: installing npm packages from the cache

npm has a feature where you can ask it to install packages from the cache, where cache-min forces npm to avoid installing packages younger than that value:

npm --cache-min 9999999 install <package-name>

This works, but I’m never going to remember that syntax, so I added an alias to my .bashrc file:

alias npmoffline="npm --cache-min 9999999 "

So now when I’m offline on a plane and want to install a package that I’ve already installed in the past (and so I know is in the cache), I can write this:

npmoffline install <package-I-already-installed>

and it will pull the contents from my cache.

Yayyy 🎉

If it doesn’t work you can also list the contents of the cache with

npm cache ls

and see what packages and versions have been cached. Perhaps you can also grep it, to discard the packages you’re not interested in, e.g. the following will only list entries related to node-firefox:

npm cache ls | grep node-firefox

Loading webcomponents-lite with require()

I just realised that the Web Components polyfills not only are in npm so you can install them like this:

npm install --save webcomponents-lite

but they also have a well formed package.json with a main entry.

So if you’re writing your front-end code with Browserify and want to load the polyfill without adding an additional script tag, you can do this:


and this pulls the polyfill into the scope.

NICE! Thanks, Addy :-)

PS I guess this should also work with webpack, if you’re so inclined.

Enabling Wi-Fi direct on your rooted Firefox OS device

I’m doing some research and playing with this new-ish API which is available in Firefox OS on rooted phones with Certified apps etc etc. Guillaume wrote a post on the Hacks blog–read it if you’re interested in what can be accomplished.

The very first thing you need to do is to enable Wi-Fi direct on the device. This involves running some commands as root, via adb. Justin made a gist which worked with Flame phones, but it didn’t work with a Nexus 4, because of the way the /system partition is mounted on those phones.

A (more?) fail-proof way should be this:

adb shell "mount -o rw,remount /system"
adb shell "stop b2g"
adb shell "echo \"ro.moz.wifi.p2p_supported=1\" >> /system/build.prop"
adb shell "mount -o ro,remount /system"
adb reboot

this will add a line to the /system/build.prop file and reboot the device.

Once it’s rebooted, the result of navigator.mozWifiP2pManager.enabled should be true, which is GOOD NEWS!

Remember that you need to run that code in

  1. a certified app
  2. request the wifi-manage permission in the manifest

So essentially your manifest.webapp MUST contain the following fields in addition to the rest of fields you usually have:

  "type": "certified",
  "permissions": {
    "wifi-manage": "for wi-fi direct"

Binding to an specific host with express.js

The documentation on the listen method is really vague, but the way you can make your server listen to an specific address only is this:

var server = app.listen(3000, '', 511, onServerListening);

In this case I want the server to respond only to connections using the host name. Not, and not localhost. Only

The reason for this is that I am playing with Twitter’s OAuth and I was stumbling upon this issue because express insisted in binding to by default (i.e. any address), but it wouldn’t work well when Twitter redirected back after authenticating.

For reference, another thing I tried and didn’t work:

var server = app.listen(3000, '', onServerListening);

Notice that the 511 parameter is missing. So effectively it would take onServerListening as if it was the 511 parameter, which according to the documentation is “the maximum length of the queue of pending connections” and it wouldn’t call the callback. Booo.


I found this little development server built with node.js and I thought I’d recommend it to you since it fixes most of the annoyances I have with the traditional SimpleHTTPServer Python solution. You can install it globally with:

npm install -g lute

And then you can enjoy…

1) Automatic port management

It will find a new available port if the default is in use, so you don’t have to manually manage this, which can be cumbersome when you need to have several local servers running at the same time. Just type


and TA-DA! you get a local server with autoassigned port, serving the files in the current directory.

Or you can also force it to use an specific port:

lute -p 3030

2) It can trigger the ‘open’ action in your browser

You can write this on your command line

lute open

and it will open localhost at whatever port it found, using your default browser.

3) Automatically injects livereload in your scripts

This can be both a blessing and an annoyance–it is not playing too well with HTML imports:

A call to document.write() from an asynchronously-loaded external script was ignored.

An issue has been diligently filed.

If you’re not using HTML imports you will be able to enjoy changing things on your code and getting them instantly autoreloaded in the browser–so you can save a few keystrokes!