Building Pulsar

If you want to investigate a bug, implement a new feature in Pulsar’s core, or just tinker, you’ll need to build and run Pulsar from source.

The Pulsar application code can be found in the pulsar-edit/pulsar repository.

Requirements and dependencies

To build Pulsar you will need to meet some basic requirements:

• An installation of Node. We endeavor to keep .nvmrc updated with the best version of Node to use (allowing users of nvm to select the correct version more easily), but technically the best version of Node to use is the one that corresponds to the version of Electron that’s being used on the master branch (or whichever branch you’re building).

  You can determine the correct version of Electron by looking for the electronVersion key in package.json for the branch you’re building.

  We strongly recommend that you use a version manager like nvm or asdf instead of relying on whatever Node may be installed globally on your system.

• yarn (enable with corepack enable; further instructions below).

• Recent versions of Git and Python 3.

• A C++ compilation toolchain.

For OS- or distribution-specific instructions, see below:

# Install development packages
apt install build-essential libsecret-1-dev libx11-dev libxkbfile-dev libxkbcommon-dev libxkbcommon-x11-dev libxkbcommon0 xkb-data libwayland-dev libwayland-client0 python3-setuptools pkg-config

# Install development packages
dnf --assumeyes install make gcc gcc-c++ glibc-devel git-core libsecret-devel rpmdevtools libX11-devel libxkbfile-devel libxkbcommon-devel nss atk gdk-pixbuf2 gtk3 mesa-dri-drivers wayland-devel libwayland-client

# Install development packges
pacman -S base-devel libxkbfile libsecret libx11 libxcrypt-compat libxkbcommon libxkbcommon-x11 wayland

# Install development packages
zypper in -t pattern devel_basis
zypper in libX11-devel libxkbfile-devel libsecret-devel libxkbcommon libxkbcommon-x11-0 libxkbcommon0 libwayland-client0 wayland

Building and running the application

Check out the code

First, check out the source to a directory of your choosing.

git clone https://github.com/pulsar-edit/pulsar.git && cd pulsar

Pick the right Node version and ensure Yarn is present

Switch to the correct version of Node for the project; if you’re running nvm, this should be as simple as nvm install (which will install the version of Node specified in specified in pulsar/.nvmrc, or else use it if it’s already installed). Then, in order to get yarn, you’ll need to run corepack enable.

nvm install # Or the equivalent for your version manager
corepack enable

You’ll only need to run corepack enable the first time for a given version of Node.

Certain tool version managers might require a “reshim” step here; for instance, if you’re using asdf, you should run asdf reshim to ensure it creates a shim executable for yarn.

Initialize the submodules

Run the following to initialize and update the submodules:

git submodule init && git submodule update

Build the dependencies

For reasons mainly having to do with dependency resolution, we use yarn rather than npm for installing dependencies.

Here’s how to install the dependencies for Pulsar and ppm:

yarn install
yarn build
yarn build:apm

Depending on which option you choose below, ppm might need additional configuration.

Option 1: yarn start

Here your options diverge; you can choose the one that fits your style of development best.

The first option is to run the start task; it’ll spawn a debug copy of Pulsar by invoking the electron binary directly. Logging information will go into your terminal.

yarn start

Option 2: ATOM_DEV_RESOURCE_PATH

If you have Pulsar installed already, you don’t have to build your own copy just to run it from source. Instead, do this:

1. Ensure no instance of Pulsar is currently running.
2. Set the ATOM_DEV_RESOURCE_PATH environment variable to the full path of where the Pulsar source code exists on disk.
3. Launch Pulsar with the --dev flag so that dev mode is enabled.

The exact method of doing so varies by platform, but on macOS/Linux you could do:

ATOM_DEV_RESOURCE_PATH=/path/to/pulsar pulsar --dev .

direnv is a handy way of associating certain environment variables with certain working directories and might make this workflow even easier.

Option 3: Build binaries

The first two options are great for iterating on changes to the Pulsar source code, but they don’t actually build the app as a standalone binary. For that you need the build script, invoked via yarn dist.

The build script will detect your OS and build the right binary for it; it’ll also automatically build for your system’s CPU architecture. For example, building on an x86_64 CPU will produce binaries for x86_64, and building on arm64 will only produce binaries for arm64. After running you will find your built application in pulsar/binaries.