Using nvm with Spacemacs

nvm is a version manager for Node.js, designed to be installed per-user, and invoked per-shell. nvm works on any POSIX-compliant shell (sh, dash, ksh, zsh, bash), in particular on these platforms: Unix, Mac OS, and Windows WSL. But most of the times, it is not properly identified by eshell in Spacemacs. Recently I found out a package called nvm.el by Johan Andersson.

Let’s walk you through how you can use nvm to choose different Node.js versions within Spacemacs on the fly.

Installing nvm

To install or update nvm, you should run the install script. To do that, you may either download and run the script manually, or use the following cURL or Wget command:

Add nvm.el to Spacemacs

Since there is not a standard layer that comes with Spacemacs to support nvm, we are going to use the nvm.el package to do the same. First add the nvm package to dotspacemacs-additional-packages inside your .spacemacs file.

Set node version with nvm-use

Then once the nvm package is installed you can use the nvm-use function to set the appropriate node version inside your dotspacemacs/user-config function.

Please note that you need the absolute node version passed as the parameter value here, otherwise you will get error such as No such version

You can find out the list of installed node versions using nvm:

Choosing node versions on the fly

You can also make use of the nvm-use function to choose a particular node version. Using M-x nvm-use and then typing the node version something like “v12.7.0”



Setting up Coveralls for your Ember Addons

In this tutorial, we will see how to setup automated code coverage metrics collection for your Ember addons using Coveralls and Github Actions.

Why Code coverage?

In simple terms, code coverage is the fraction or percentage of code paths executed by some test or test suite of a program. It is generally measured by a tool which executes the test and logs the lines of code, the test “touches” while running. At its most basic, every conditional statement creates a “branch” defining two unique code paths, and theoretically, both “branches” of each condition must be executed by the test suite in order for the developer to be certain that the code works correctly in each condition.

Code coverage is often used as a metric to determine the effectiveness of Unit tests. Low coverage typically means that developers are not writing adequate unit tests. This signifies that there are many code paths in the application which may possibly behave incorrectly.


This addon provisions to gather Code coverage for your Ember apps and addons using Istanbul. Install this addon into your Ember app or addon with ember install;

The latest version published on npm is 0.4.2. This might be a very old version and not Octane compatible, you might run into some errors while running the tests. But there is a latest one in Github release with the tag v1.0.0-beta.9. If you are running into any problems with the npm package , you can directly install the 1.x beta version using yarn or npm.

Or using yarn

Coverage will only be generated when an environment variable is true (by default COVERAGE) and running your test command like normal.


Coveralls is a language-agnostic and CI-agnostic web service to help you track your code coverage over time, and ensure that all your new code is fully covered.

Add your github repo for the app/addon to Coveralls using Add Repos option in the website.

After adding the repo, Coveralls will provide you with a repo token, which we need to identify the repo with Coveralls. You need to add a Github Secret with the value of this token in your repo. This will be later used in our Github actions to set up the COVERALLS_REPO_TOKEN environment variable before sending coverage information to Coveralls.

Install the coveralls node package.

Configure your test script to include coverage information.

Add a separate coveralls script to upload the coverage information to Coveralls service.

This will upload the coverage statistics generated while running tests in a folder called coverage in a file known as

Generating coverage statistics in CI

If you want to generate coverage information and upload it to Coveralls while running your tests in CI whenever you push your code to the repo or whenever a pull request is raised, you can go for some automated CI setup using Travis or Github Actions. In this tutorial we are going to look at how we can achieve this using Github Actions.

Github actions for Coveralls

This GitHub Action posts your test suite’s LCOV coverage data to for analysis, change tracking, and notifications. You don’t need to add the repo to Coveralls first, it will be created when receiving the post.

When running on pull_request events, a comment will be added to the PR with details about how coverage will be affected if merged.

Create a new job for your Github Actions or add it part of the existing one.

If you want to see the above setup in action, please take a look at my ember-chance addon repo.

Optional Goodies: README Badge

And finally if you want to add the coverage statistics as a badge in your README, you can do so by adding the following snippet at the top of your README file, which will show how much the coverge % is for your addon.

Please ensure to replace the above snippet with the appropriate values for the placeholders like <github-user-name> and <repo-name>


  1. Install ember-cli-code-coverage
  2. Install coveralls from npm
  3. Modify the test script in package.json to include COVERAGE=true
  4. Add a new script for coveralls to upload the coverage info
  5. Add your repo to and get the repo_token
  6. Add a Github secret with the value of the repo_token in the repository
  7. Setup automated coverage collection in CI using Coveralls Github Actions



The Craftsman – Mind Map

In this post, we are going to share you a mind map of the book called The Craftsman by Richard Sennett.

Richard Sennett is a prime observer of society … one of his great strengths, the thing that makes his narrative so gripping, is the sheer range of his thinking and his brilliance in relating the past to the present.

The Craftsman is a complex but very rewarding read about craftsmanship, pride in one’s work and the differences between individual work and mechanical production, and the intellectual investment in the former versus the more mechanistic approach in the latter.

The Craftsman by Richard Sennett

Sennett uses many examples from the world of music to illustrate his thesis and he finishes with an explanation of the philosophical underpinnings of his ideas, pragmatism in this case.
This book has an extensive index and bibliography and his examples are well-chosen and illustrative and evidence of his wide understanding of the matter. Not a book to read on the beach or a plane or even at home in a week or so. It requires time and patience and is rewarding even when dipping into individual sections but the real benefit comes with the final section brings together the threads and leaves the reader with much more understanding of this field of human endeavor than one had before.


A guide to create tmux like Custom Layouts in Spacemacs

Coming from a vim world with tmux, I had really missed the multiple split window layout in Spacemacs. But after knowing how to define custom layouts this seemed to be an easy exercise for me.

So I thought, I should write a blog post about it to help others setup awesome layouts and workspaces with Spacemacs.

Some Terminology

Here I want to make some clarifications on the terminology surrounding vim, tmux and Emacs on windows, layouts, panes and buffers.


vim: Buffers

A buffer is the in-memory text of a file which is actually an area of Vim’s memory used to hold text read from a file for editing. In addition, an empty buffer with no associated file can be created to allow the entry of text.

vim: Windows

A window is a viewport onto a buffer. You can use multiple windows on one buffer, or several windows on different buffers.

Vim provides multiple ways to organize your work, one of them being the ability to open multiple split windows within the same tab page of a given Vim instance. This allows you to have multiple views on the same buffer or file, or even view multiple buffers side-by-side or in any arrangement you prefer.

vim: Tabs

A tab page is a collection of windows.

Emacs: Frames

A frame is a screen object that contains one or more Emacs windows. It is the kind of object called a “window” in the terminology of graphical environments; but we can’t call it a “window” here, because Emacs uses that word in a different way.

A frame initially contains a single main window and/or a minibuffer window; you can subdivide the main window vertically or horizontally into smaller windows.

Emacs: Windows

A window is an area of the screen that is used to display a buffer.

Windows are grouped into frames. Each frame contains at least one window; the user can subdivide it into multiple, non-overlapping windows to view several buffers at once.


Each window displayed by tmux may be split into one or more panes; each pane takes up a certain area of the display and is a separate terminal.

Spacemacs: Layouts

Layouts are window configurations with buffer isolation, each layout can define several workspaces (think of them as sub-layouts) sharing the same list of buffers as their parent layout.

A layout is a window configuration associated with a list of buffers. The list of buffers can be an arbitrarily chosen set of buffers. Spacemacs provides some facilities to create meaningful sets of buffers, for instance the buffers related to a projectile project.

Spacemacs: Workspaces

Workspaces are sub-layouts, they allow to define multiple layouts into a given layout, those layouts share the same buffer as the parent layout.


A number of preset layouts are available in tmux. They are:

  • even-horizontal
  • even-vertical
  • main-horizontal
  • main-vertical
  • tiled

We will see each one in detail and also learn how to create each type of layout in Spacemacs

Custom Layouts

Custom layouts in Spacemacs can be defined using the macro spacemacs|define-custom-layout, they are accessible via SPC l o. You can define these custom layouts inside your.spacemacs file under dotspacemacs/user-config section.

Even Horizontal Layout

Panes are spread out evenly from left to right across the window.

Even Vertical Layout

Panes are spread evenly from top to bottom.

Main Horizontal Layout

A large (main) pane is shown at the top of the window and the remaining panes are spread from left to right in the leftover space at the bottom. Use the main-pane-height window option to specify the height of the top pane.

Main Vertical Layout

Similar to main-horizontal but the large pane is placed on the left and the others spread from top to bottom along the right.

Tiled layout

Panes are spread out as evenly as possible over the window in both rows and columns.

Example Custom Layout

So far we have seen how we can create custom layouts like tmux standard presets in Spacemacs. But the above examples are only skeletons, we don’t load any files in the windows. Now we will see an actual example of how to create accessible custom layouts by loading the desired files, terminals and other programs inside Spacemacs.

Custom Layout in Spacemacs

Previously, in vim, I have been using tmuxinator for managing my tmux sessions and custom layouts for my projects. Since I will be working on multiple projects simultaneously, it was really helpful to define a standard and unique layout for each project.

Layout definition using tmuxinator

tmuxinator is a tool to manage complex tmux sessions easily. It has got some layout settings gets handed down to tmux directly, so you can choose from one of the five standard layouts or specify your own.

The above same configuration can be easily ported to Spacemacs like below. All you need to do is to get familiar with different macros that are available in Spacemacs like find-fileeshellsplit-window-right, etc., Once you know how these macros work, it will be an easy task to setup custom layouts like this.

The resultant layout will look something similar to this: