# Pulsar: the community fork that kept Atom's package model alive

> Pulsar is a community-led text editor forked from Atom and built on Electron, MIT licensed, with a package system carried over from Atom. Here is how it installs, how plugins work, and where the fork's limits show.

**pulsar-edit/pulsar** — A Community-led Hyper-Hackable Text Editor

- Repository: https://github.com/pulsar-edit/pulsar
- Website: https://pulsar-edit.dev
- Stars: 4,162 · Forks: 197
- Language: JavaScript
- License: NOASSERTION
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/pulsar-edit-pulsar

## What Pulsar is, and who the fork is for

Pulsar describes itself in its README as "A Community-led Hyper-Hackable Text Editor, Forked from Atom, built on Electron." The upstream project it forked from is gone: the README links to GitHub's post about sunsetting Atom, and the badge set in the repository still carries an "Upstream Status: Sunset" label. So the problem Pulsar addresses is narrow and concrete. People had editing workflows, keymaps, themes and packages tied to Atom's APIs, and the host application for those APIs stopped receiving updates. Pulsar is the continuation of that host.

The audience follows from that. It is for people who want to change how their editor behaves, not just configure it. The README states the design goal directly: "Designed to be deeply customizable, but still approachable using the default configuration." The package list in package.json makes the depth visible. Editing primitives such as @pulsar-edit/text-buffer, @pulsar-edit/atom-keymap, @pulsar-edit/superstring and @pulsar-edit/pathwatcher are scoped under the pulsar-edit organisation, and a long row of bundled packages (about, archive-view, autocomplete-css, autocomplete-html, and more) ships as file: links inside the repository. That is not a plugin marketplace bolted onto a closed core. The bundles are part of the build.

## The architecture: Electron shell, JavaScript packages, ppm

Pulsar is an Electron application. package.json pins electronVersion to 32.3.3 and points main at ./src/main-process/main.js, so the main process is plain JavaScript run by Electron's Node side. The editor window and every UI surface are rendered by the same framework Atom used, which is why Atom themes and UI packages can still be installed.

On top of that sits the package system. The repository contains a ppm directory at the top level, which is the Pulsar Package Manager, and a pnpm-workspace.yaml alongside yarn.lock, so the project itself is developed as a workspace. Packages are JavaScript, CoffeeScript or a mix, and they hook into the editor through the same service and activation model Atom documented. That is the mechanism behind "hyper-hackable": a package can register commands, keybindings, grammar scopes, view components and background services, and the editor loads it at startup.

The rest of the tree reflects a mature Electron codebase rather than a small utility. There are keymaps/, menus/, locales/ for translations, spec/ for unit tests, integration/ with a playwright.config.ts for end-to-end tests, and a vendor/ directory. The engines field requires Node >=20.18.1, which matters if you intend to build from source rather than install a release.

## Installing Pulsar and installing your first package

The README does not carry install instructions inline. It links to the documentation at docs.pulsar-edit.dev, and specifically to a getting-started page titled "Installing Pulsar" at docs.pulsar-edit.dev/getting-started/installing-pulsar/. That page is the authoritative source for platform-specific packages, and it is where you should look for the download for your system. The repository also exposes a pulsar.sh script at the top level and a script/ directory, which are the build entry points used by contributors.

If you build from source instead of installing a release, the README points at docs.pulsar-edit.dev/contributing-to-pulsar/building-pulsar/. The repository's own constraints apply: Node 20.18.1 or newer, and a workspace that uses pnpm. The version in package.json is 1.132.1-dev, while the most recent tagged release is v1.132.1 from 2026-05-20, so a source checkout sits one development cycle ahead of the release you would download.

Once Pulsar is running, packages are managed through the ppm tool that ships in the repository's ppm directory. The repository does not document the individual ppm subcommands in the files available, so the reliable path is the editor's own package manager UI, which is the interface the project points users at. That UI performs the install and uninstall operations for you and avoids any PATH setup.

For package authors, the repository layout matters more than the UI. The pnpm-workspace.yaml at the top level defines the workspace, and bundled packages are wired in through file: dependencies in package.json, for example "about": "file:packages/about" and "archive-view": "file:packages/archive-view". That pattern is how a local package directory gets loaded by the editor during development:

```json
"about": "file:packages/about",
"archive-view": "file:packages/archive-view"
```

Pointing a dependency at a file: path inside the repository is what makes the editor pick up your working copy instead of a published version. Remove or change that entry when you are done, otherwise the editor keeps loading your local directory.

## Where the fork model hurts: package coverage and stale APIs

The honest limitation is inheritance. Pulsar keeps Atom's package API stable so that existing packages keep working, and that same stability means the API carries Atom's design decisions forward. Electron has moved on since Atom's last release, and Pulsar pins electronVersion 32.3.3 in package.json. Every dependency that reaches into Electron internals, such as @electron/remote, is a place where an upstream Electron change can force work in the fork rather than in the package. Package authors who stopped maintaining their Atom packages are not automatically rescued by Pulsar existing; a package that broke against a newer Node or a newer Electron still needs someone to fix it.

There is a second, quieter cost. Because the project is a workspace with dozens of bundled packages, the surface area that a change can affect is large. The presence of .codacy.yaml, an ESLint configuration, a Cirrus CI status badge, a Crowdin project for translations and a Playwright integration suite tells you the project has built the machinery to manage that surface. It does not tell you the machinery is cheap to run. Contributors should expect the build instructions to be longer than the README, which is exactly why the README links out to a separate building guide instead of inlining one.

Finally, the repository metadata does not settle the licence question for you. package.json declares "license": "MIT", and the README's badge row shows an MIT badge, but the hosting platform reports the repository licence as NOASSERTION. The repository does contain a LICENSE.md at the top level. Read that file rather than the badge if the distinction matters to your organisation.

## How Pulsar differs from VS Code and from a plain text editor

The obvious alternative is Visual Studio Code. The difference in approach is not cosmetic. VS Code runs extensions in a separate extension host process and exposes a curated API surface, which constrains what an extension can do but keeps the editor core insulated. Pulsar inherits Atom's model, where a package runs inside the editor's own processes and can reach much deeper into the UI, the text buffer and the keymap. That is why a Pulsar package can restyle or replace core interface elements in ways a VS Code extension cannot, and it is also why a badly behaved package can degrade the whole editor. If you want a plugin to be unable to hurt the host, Pulsar is the wrong side of that trade.

The other comparison is against a plain editor with no plugin runtime at all. Pulsar's default configuration is described in the README as approachable, and the bundled packages mean a fresh install is a working editor rather than an empty shell. But you are still paying for an Electron runtime and a JavaScript package layer on every launch. For someone editing a handful of config files a week, that cost buys nothing. The choice only makes sense when you actually intend to modify the editor's behaviour.

## Maintenance, releases and what an upgrade costs

The repository is not archived, and the last push recorded for it was 2026-09-23, so development activity is current. Releases are tagged at a steady cadence: v1.131.3 on 2026-03-20, v1.132.0 on 2026-05-17 with the release title "Pulsar 1.132.0: The terminal is now boarding", and v1.132.1 on 2026-05-20. The gap between v1.132.0 and v1.132.1 is three days, which is the shape of a patch release following a feature release rather than a long stabilisation period.

The upgrade cost for a user is mostly package compatibility. Because Pulsar keeps the Atom package API stable, most upgrades should not touch your installed packages, but the electronVersion pin in package.json is the thing to watch across major releases. When that number moves, native modules and packages that use Electron internals are the ones that need attention. Checking the editor's package list before and after an upgrade is the cheapest way to notice a package that failed to load.

For contributors, the cost is the workspace itself. Node >=20.18.1 is required, the build is driven by the scripts under script/ and pulsar.sh, and the test surface spans spec/ and the Playwright integration suite. That is a real onboarding cost, and the project's decision to keep the build documentation outside the README suggests it is deliberate rather than an oversight.

## Conclusion

Adopt Pulsar if you still depend on Atom packages and want a maintained Electron host for them, or if you want to write editor behaviour in JavaScript and CoffeeScript rather than a compiled extension language. Do not adopt it if you need a small binary, low memory use, or a plugin ecosystem with the reach of VS Code's. Before committing, check that your specific Atom packages still load, confirm that the ppm tool is available for your platform, and read LICENSE.md in full, since the repository metadata does not identify the licence text for you.

## FAQ

### What is Pulsar?

Pulsar is a community-led text editor forked from Atom and built on Electron, described in its README as a hyper-hackable editor that is deeply customizable but still approachable with the default configuration.

### How do I install Pulsar?

The README links to a getting-started page at docs.pulsar-edit.dev/getting-started/installing-pulsar/, which is where the platform-specific install instructions live. The README itself does not inline the install steps.

### How do I install a package in Pulsar?

The repository contains a ppm directory, which is the Pulsar Package Manager, but the files available do not document its subcommands. The editor's own package manager UI is the documented interface for installing and removing packages.

### Can Pulsar run existing Atom packages?

Pulsar is forked from Atom and keeps the same package model, with Atom-era editing primitives such as text-buffer, atom-keymap and superstring now maintained under the pulsar-edit scope. Packages that stopped being maintained upstream are not automatically fixed by the fork.

### What licence is Pulsar under?

package.json declares "license": "MIT" and the README shows an MIT badge, but the repository metadata reports the licence as NOASSERTION. A LICENSE.md file sits at the top level of the repository, so read that file for the actual terms.

## Sources

- [Issues](https://github.com/pulsar-edit/pulsar/issues)
- [Project website](https://pulsar-edit.dev)
- [pulsar-edit/pulsar on GitHub](https://github.com/pulsar-edit/pulsar)
- [README](https://github.com/pulsar-edit/pulsar/blob/master/README.md)
- [Releases](https://github.com/pulsar-edit/pulsar/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pulsar-edit-pulsar