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.
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:
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”
In this tutorial, we will see how to setup automated code coverage
metrics collection for your Ember addons using
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
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
ember install ember-cli-code-coverage
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.
Coverage will only be generated when an environment variable is
true (by default COVERAGE) and running your test command like
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.
This will upload the coverage statistics generated while running
tests in a folder called coverage in a file known as lcov.info
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
coveralls.io 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
If you want to see the above setup in action, please take a look
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.
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.
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.
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.
Here I want to make some clarifications on the terminology surrounding vim, tmux and Emacs on windows, layouts, panes and buffers.
Buffers Windows Tabs
Buffers Frames Windows
Buffers Frames Windows Layouts Workspaces
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.
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.
A tab page is a collection of windows.
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.
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.
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.
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:
We will see each one in detail and also learn how to create each type of layout in Spacemacs
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.
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-file, eshell, split-window-right, etc., Once you know how these macros work, it will be an easy task to setup custom layouts like this.