Global npm Module Weirdness

I just installed node 8.9.1 with nodenv. Then I wanted to get my global packages installed to more-or-less match what I had with my previous version of node (v6.11.3).

Running npm list -g --depth=0 with node 6.11.3 active gives me:

❯ npm list -g --depth=0
├── eslint@4.7.1
├── eslint-config-airbnb-base@12.0.0
├── eslint-config-prettier@2.5.0
├── eslint-plugin-import@2.7.0
├── eslint-plugin-json@1.2.0
├── eslint-plugin-prettier@2.3.1
├── generator-code@1.1.20
├── gulp@3.9.1
├── npm@3.10.10
├── prettier@1.7.3
├── prettier-eslint@8.2.0
├── vsce@1.31.1
└── yo@2.0.0

So with node 8.9.1 active I ran npm i -g eslint gulp prettier prettier-eslint yo generator-code to start installing a bunch of — but not all of — the global packages that I wanted.

Now for the weird part: Running npm list -g --depth=0 to see the current state of the world gives me this:

❯ ng # <-- a handy alias for `npm list -g --depth=0`
├── generator-code@1.1.22
├── gulp@3.9.1
├── npm@5.5.1
├── prettier-eslint@8.2.2
└── yo@2.0.0

eslint isn’t listed as a global package! But I have it installed:

❯ which eslint; and eslint -v

I looked a little deeper and found eslint installed as a dependency of prettier-eslint (which, by the way, is not a module that I actually wanted to have installed globally):

❯ npm list -g --depth=1
├─┬ prettier-eslint@8.2.2
│ ├── ...
│ ├── eslint@4.11.0

And further, digging into where nodenv actually stores the globally installed modules, in this case ~/.nodenv/versions/8.9.1/lib/node_modules, I see that eslint is indeed there at the top level!


So the question is:

Why doesn’t npm list eslint as a top-level globally installed module when it seems as though it is one?

The follow up question is: Why does it bother me as much as it does that eslint doesn’t show up in that list of global modules even though everything works as though it is a top-level global module?

The Fix

How to fix this “problem”? One option is to just blow away all of the globally installed packages by running this a couple of times:

npm ls -gp --depth=0 | awk -F/ '/node_modules/ && !/\/npm$/ {print $NF}' | xargs npm -g rm

That’s extreme and is likely something that you wouldn’t want to do in most situations.

The other option is to remove the package that has eslint as a dependency, which is a package I didn’t want to have installed in the first place: npm -g rm prettier-eslint

Now the world is happy again:

❯ ng
├── eslint@4.11.0
├── generator-code@1.1.22
├── gulp@3.9.1
├── npm@5.5.1
├── prettier@1.8.2
└── yo@2.0.0

Final Note

At this point reinstalling prettier-eslint works and eslint still shows up as a global package.

BTT: Three Finger Swipes

This is a quickie. One of my most-used BetterTouchTool configurations is setting up three finger swipes. Three of my most used global shortcuts are:

  • Three finger swipe left — ⇧⌘[ (Show Previous Tab)
  • Three finger swipe right — ⇧⌘] (Show Next Tab)
  • Three finger swipe down — ⌘W (Close Current Tab (or Window))

Being able to use three fingers to swipe between an app’s tabs, and then quickly close a tab with a swipe down, feels like an entirely new way to casually do light work.

`git push` Without Complaints

On my work computer, I can make a new git branch and push it up to GitHub with a simple git push. I don’t need to manually set or create the upstream branch. Not so on my home computer. At least not when working on my dotfiles repo. When I try to push up a new branch, I get this error:

fatal: The current branch new-branch has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin new-branch

It didn’t take too long to figure out the problem. Somewhere along the line I’d renamed the default remote from origin to github. I saw this by looking at the repo’s .git/.gitconfig file, which had the following lines:

[remote "github"]
    url =
    fetch = +refs/heads/*:refs/remotes/github/*
[branch "master"]
    remote = github
    merge = refs/heads/master

I changed github to origin on the first and fifth lines, so it read:

[remote "origin"]
    url =
    fetch = +refs/heads/*:refs/remotes/github/*
[branch "master"]
    remote = origin
    merge = refs/heads/master

After that, no more complaints when trying to push up a branch that didn’t yet exist on GitHub.

I’m pretty sure that tomorrow’s post will be a follow up explaining how I could keep my remote branch named github and still allow for auto-creation of remote branches. Stay tuned for that excitement.

P.S. You might also need to check the value of git’s push.default setting with $ git config --global push.default. It it’s not current, then run git config --global push.default current. In my case, this was already set, but I don’t believe it’s like this out of the box.

Faster GitHub PRs, Take 2

I just updated the function I wrote about yesterday, making two big changes:

  • Vim is no longer opened just so that I can reuse the last commit message for the PR Message
  • The browser no longer opens the PR page; instead the URL for the PR is copied to the clipboard so that I can paste it into Slack.

The new usage is simply $ pr if I want to PR into develop or $ pr target-branch if I want to PR into target-branch.

Here is the new version, which can also be found on GitHub:

function pr -d 'Quickly make a PR of the current branch into `develop` or the branch of your choosing'
  # Reuse the last commit message as the PR message
  git log -1 --pretty=%B > msg.txt
  set targetbranch 'develop'
  if test -n "$argv"
    set targetbranch $argv[1]
  git push; and git pull-request -b $targetbranch -F msg.txt | pbcopy
  rm msg.txt
  echo 'You can find your PR at' (pbpaste)
  echo ' (That URL has been copied to your clipboard, as well)'

I’m outputting the last commit message to a temp file, msg.txt, because this seems like a good way to support multi-line messages. The message is then used with the pull-request -F flag. In my first attempt I stored the value of git log -1 --pretty=%B in a var to then pass to pull-request -m but that choked on commits that were more than a single line.

Faster GitHub PRs

NOTE: The day after writing this, I made it better

After some setup, I can create a GitHub PR with two commands in the terminal: Entering pr at the command line followed by :x in Vim. After that I’m staring at the webpage for the PR in my browser.

How? With a command line function that leverages Hub for GitHub.

Want to do the same?

First, install Hub for GitHub. With Homebrew it’s as simple as $ brew install hub. You’ll also want to follow the simple instructions to alias git to hub. In effect this just gives git some extra powers.

Now you can type $ git pull-request -b develop -o which will:

  1. Prompt you to enter a message for the PR in whatever editor you’ve told Git to use
  2. Open the webpage for the newly created PR in your browser

But who wants to type that much? The logical next step is to make a shell function so you can just type pr. In Fish, it looks like this:

function pr
  set targetbranch 'develop'
  if test -n "$argv"
    set targetbranch $argv[1]
  git push; and git pull-request -b $targetbranch -o

Now creating PRs into develop is as simple as $ pr and making PRs into my-big-feature can be done with $ pr my-big-feature. And with Fish’s autosuggestions you likely won’t even have to type more than a letter or two of your target branch’s name.


One way this could be better is if the URL for the PR page on GitHub could be copied to my clipboard so I could easily paste it into my team’s Slack channel. In fact, the only reason I want to open the PR page at all is so that I can grab its URL. It doesn’t seem like the pull-request command has a way to just give me the URL. Let me know if I missed that. But since this process ends with me looking at the page I want to share it just takes a quick ⌘L ⌘C to get the URL on my clipboard. Not too shabby.

Run ffmpeg On a Folder of Videos

The Problem:

I had roughly fifty video files across four different folders that I wanted to extract the audio from. You can use ffmpeg to pull the audio out of a single video file, but I didn’t want to type in a slightly different ffmpeg command fifty times.

The Solution:

Write a Node.js script that loops over all the files in a directory and runs the correct ffmpeg command to attempt to extract the audio from each file. And, of course, spend more time writing the script than it would have taken to just manually run the command dozens of times.

You can grab the script from GitHub. It was a fun learning experience. When you run the ffmpeg command, you need to make sure that the file extension for the audio file matches the format that’s actually in the movie file. This is kind of a drag. It would be nice if ffmpeg was smart enough to extract whatever audio was in the video, in whatever format it was in. It’s entirely possible it is that smart, I’m just not smart enough to know how to make it do what I want. At any rate, my script allows you to pass in an argument to set what format the audio is in.

Oh, all you care about is the ffmpeg command that’ll pull the existing audio out of a video file? No problem: ffmpeg -i input-video.avi -vn -acodec copy output-audio.mp3

Rails 5 Installation Woes

I ran into issues installing Rails 5 today. It was blowing up trying to install the Nokogiri gem. The full error message is at the bottom of this post, if you’re curious (and for the benefit of SEO).

The fix was to install the Xcode Command Line tools. This, despite the fact that I have the latest version of Xcode installed. So after running:

$ xcode-select --install

I could run gem install rails without issue. Weird.

FWIW, I’m running OS X 10.11.5 and Ruby 2.3.1 installed via rbenv.

Full output of the errors thrown when trying to install Nokogiri:

$ gem install nokogiri
Building native extensions.  This could take a while...
ERROR:  Error installing nokogiri:
    ERROR: Failed to build gem native extension.

    current directory: /Users/erikhansen/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/nokogiri-1.6.8/ext/nokogiri
/Users/erikhansen/.rbenv/versions/2.3.1/bin/ruby -r ./siteconf20160703-99836-186h6s0.rb extconf.rb
Using pkg-config version 1.1.7
checking if the C compiler accepts ... yes
checking if the C compiler accepts -Wno-error=unused-command-line-argument-hard-error-in-future... no
Building nokogiri using packaged libraries.
Using mini_portile version 2.1.0
checking for iconv.h... yes
checking for gzdopen() in -lz... yes
checking for iconv... yes

Building Nokogiri with a packaged version of libxml2-2.9.4.

Team Nokogiri will keep on doing their best to provide security
updates in a timely manner, but if this is a concern for you and want
to use the system library instead; abort this installation process and
reinstall nokogiri as follows:

    gem install nokogiri -- --use-system-libraries

If you are using Bundler, tell it to use the option:

    bundle config build.nokogiri --use-system-libraries
    bundle install

Note, however, that nokogiri is not fully compatible with arbitrary
versions of libxml2 provided by OS/package vendors.
Extracting libxml2-2.9.4.tar.gz into tmp/x86_64-apple-darwin15.5.0/ports/libxml2/2.9.4... OK
Running 'configure' for libxml2 2.9.4... OK
Running 'compile' for libxml2 2.9.4... ERROR, review '/Users/erikhansen/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/nokogiri-1.6.8/ext/nokogiri/tmp/x86_64-apple-darwin15.5.0/ports/libxml2/2.9.4/compile.log' to see what happened. Last lines are:
    unsigned short* in = (unsigned short*) inb;
encoding.c:815:27: warning: cast from 'unsigned char *' to 'unsigned short *' increases required alignment from 1 to 2 [-Wcast-align]
    unsigned short* out = (unsigned short*) outb;
4 warnings generated.
  CC       error.lo
  CC       parserInternals.lo
  CC       parser.lo
  CC       tree.lo
  CC       hash.lo
  CC       list.lo
  CC       xmlIO.lo
xmlIO.c:1450:52: error: use of undeclared identifier 'LZMA_OK'
    ret =  (__libxml2_xzclose((xzFile) context) == LZMA_OK ) ? 0 : -1;
1 error generated.
make[2]: *** [xmlIO.lo] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of necessary
libraries and/or headers.  Check the mkmf.log file for more details.  You may
need configuration options.

Provided configuration options:
/Users/erikhansen/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/mini_portile2-2.1.0/lib/mini_portile2/mini_portile.rb:366:in `block in execute': Failed to complete compile task (RuntimeError)
    from /Users/erikhansen/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/mini_portile2-2.1.0/lib/mini_portile2/mini_portile.rb:337:in `chdir'
    from /Users/erikhansen/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/mini_portile2-2.1.0/lib/mini_portile2/mini_portile.rb:337:in `execute'
    from /Users/erikhansen/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/mini_portile2-2.1.0/lib/mini_portile2/mini_portile.rb:111:in `compile'
    from /Users/erikhansen/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/mini_portile2-2.1.0/lib/mini_portile2/mini_portile.rb:150:in `cook'
    from extconf.rb:364:in `block (2 levels) in process_recipe'
    from extconf.rb:257:in `block in chdir_for_build'
    from extconf.rb:256:in `chdir'
    from extconf.rb:256:in `chdir_for_build'
    from extconf.rb:363:in `block in process_recipe'
    from extconf.rb:262:in `tap'
    from extconf.rb:262:in `process_recipe'
    from extconf.rb:555:in `<main>'

To see why this extension failed to compile, please check the mkmf.log which can be found here:


extconf failed, exit code 1

Gem files will remain installed in /Users/erikhansen/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/nokogiri-1.6.8 for inspection.
Results logged to /Users/erikhansen/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/extensions/x86_64-darwin-15/2.3.0-static/nokogiri-1.6.8/gem_make.out

Better LaunchBar Arrow Keys


I like the “Vim Mode” option in LaunchBar that allows you to use the H-J-K-L keys as arrows keys if you hold down CONTROL. But, on a MacBook keyboard at least, I still find it a little awkward to press the CONTROL key. It’s not the worst thing in the world, but I figured there’s a key I can remap to CONTROL using our good friend Karabiner. Here are the things I tried, from worst to best.

The Bad Ideas

First, I tried remapping my Hyper Key to CONTROL when LaunchBar is active. It’s much easier to reach over and hold down the CAPS LOCK key with my left pinky than it is to reach down for the CONTROL key with my left pinky. I used this for a day or two but got annoyed because I found that it was pretty common for me to want to use app launching shortcuts while LaunchBar was active. But if LaunchBar was active I couldn’t use HYPER-A to switch to iTerm or HYPER-E to switch to my editor.

So I realized that simply holding down the A key could be remapped to holding down CONTROL.

  <name>Hold A to Control in LaunchBar</name>
  <appendix>Tap to enter an A character</appendix>

That’s actually easier than reaching all the way over to the CAPS LOCK key with my pinky. The problem is that I found that if I was typing fast enough LaunchBar would lose keystrokes. For example, if I typed “kar” to launch Karabiner, the only thing that would get entered into LaunchBar was a single K.

The Good Idea

How about if I have to hold down two characters at once to simulate CONTROL? Sounds great! If I hold down D and F together, that will act like I’m holding down CONTROL:

  <name>D+F together to Control in LaunchBar</name>
    KeyCode::D, KeyCode::F,

    KeyCode::CONTROL_L | ModifierFlag::NONE,

This seems to work great. I can’t find a problem with it. But there’s an even better way.

The Best Solution

There’s a built-in Karabiner option called Simultaneous Vi Mode.


When you turn it on, you can hold down S and D together so that you can use the H-J-K-L keys as arrows keys anywhere in the system. Brilliant. I’ve had this turned on for a few minutes and have already found it useful.1 I also like that with this option, Karabiner pops up a little notification-style HUD in the bottom-right corner of the screen to let you know that this mode is active.

Karabiner HUD
Karabiner HUD

  1. I did notice that very rarely I’d type an “s” and “d” fast enough that Karabiner would turn on Vi Mode and my keystrokes didn’t register. To fix this I adjusted the Simultaneous Key Presses > Delay Threshold of Key in the Parameters tab. Its default value is 50ms. Turning it down to 40ms seems to prevent the accidental triggering. 

iTerm2 v3 and LaunchBar

If you are running the iTerm2 v3 beta and have iTerm set as your preferred terminal application in LaunchBar’s preferences, you may have noticed that LaunchBar’s terminal commands will not work. For example, selecting a path in LaunchBar and then choosing the Open Terminal Here command (or simply hitting ⌘T), fails silently. Read more here or check out this Twitter conversation.

I came up with two different ways to deal with this.

First, here are two LaunchBar actions you can install. One is used to open a path in a new iTerm tab and the other is to open a path in a new iTerm window.

Second, if you really want LaunchBar’s ⌘T shortcut to open the selected directory in iTerm2 v3, I put together a hack that will do just that. Getting that all set up is more involved than just installing a LaunchBar action but it’s not that bad.

The LaunchBar team has known about this issue for some time now. I suspect that they haven’t changed things on their end because iTerm2 v3 has been in beta. Looks like iTerm2 v3 will be “official” very soon and when that happens, I suspect that LaunchBar with be updated. At that point, these actions and hacks won’t be needed. Until then, they should fill the gap for you well enough.

Karabiner + LaunchBar

I’ve been digging into Karabiner over the past couple of days. It’s been bending my mind a little bit. One thing I wanted to do was assign a key-for-key remap, but only when LaunchBar has focus. This was problematic because LAUNCHBAR never became the active app as far as Karabiner was concerned.1 So any <item> that you create that contains <only>LAUNCHBAR</only> will never fire because Karabiner never knows that LaunchBar is active. Then I stumbled across the built-in options for LaunchBar in Karabiner’s Change Key pane. If you check the Open LaunchBar by command-space option, Karabiner will recognize when LaunchBar is active so you can write remaps that work only with LaunchBar.2 Sweet. That’s exactly what I’m looking for.3 The trick seems to be explicitly opening LaunchBar with KeyCode::VK_OPEN_URL_APP_Launchbar.


As an added note, there’s a built in rule you can turn on that’ll remap hitting F and J together to invoke LaunchBar. Or, more specifically, it just remaps a simultaneous press of the F and J keys to ⌘-SPACE. But this will invoke LaunchBar without Karabiner knowing that it’s active. So here’s a rule you can add to your custom.xml that’ll activate LaunchBar and work with Karabiner remaps that target LaunchBar.

  <name>Press F+J Together to Invoke LaunchBar</name>
  <appendix>Invoke LaunchBar and make it the active app</appendix>
  <appendix>so that Karabiner remaps that target LB work</appendix>
    KeyCode::F, KeyCode::J,


  1. You can observe this by opening the Karabiner EventViewer from the menubar item and switching to the App tab. 
  2. By the way, choosing the option to map the semicolon key to return when LaunchBar is active might be something that I can really get used to. 
  3. Okay, maybe this isn’t exactly what I want. I’ve noticed that with this option enabled, it takes an extra tap of the space bar to activate LaunchBar’s app switcher. Normally, you could invoke LaunchBar, hit space, and you’d be at the previously used app. It’s pretty quick. But now you need to invoke LaunchBar and hit the space bar TWO times to get back to the previous app. Kind of a pain in the ass, but it’s really one of my own creation since I’ve temporarily disabled the built-in ⌘-Tab app switcher