Pulsar Blog

Pulsar v1.132.0: The terminal is now boarding

2026-05-17T00:00:00Z

Pulsar 1.132.0 is available now and ready to improve your out-of-box experience!

Pulsar v1.132.0: The terminal is now boarding

This release delivers something that we hope will make most users’ lives easier, whether they’re veteran Pulsar users or brand-new users giving us a try: a new core terminal package!

Also on offer: a new experimental setting that we think will improve the experience of switching Git branches. When enabled, core.promptOnConflict will recognize when you’ve made edits against a file whose contents changed on disk after you started making the edits, and will warn you when you try to save your edits! This is one step toward improving the experience of users who often switch branches in version control.

We’ve also added a setting that might make life easier for those who routinely edit large files, quality-of-life improvements for Pulsar contributors and package authors, better window management when opening projects from the command line, new configurable behavior for autocomplete-plus, and a handful of improvements to syntax highlighting.

As always, a huge thank you to our community, contributors, and donations. Happy coding, and see you amongst the stars!
- The Pulsar Team

New terminal package!
New editor.largeFileThreshold setting that allows the user to configure the file-size threshold of the “large file mode” present in TextMate-style grammars.
New experimental setting: core.promptOnConflict. When enabled, Pulsar will ask for confirmation if you try to save an item while it’s in a “conflicted” state. You may decide whether to cancel or proceed with overwriting the file on disk. (For an editor, the “conflicted” state occurs if you open a file and make changes, but another program writes different contents to the file on disk before you can save your changes in Pulsar.) Since this setting is experimental, it is disabled by default… but we encourage users to enable it and help us test it!
Minor Electron version increase to v30.5.1.

Pulsar

Bump @pulsar-edit/fuzzy-native to 1.3.1 @savetheclocktower
Tree-sitter fixes, bonus 1.132 edition @savetheclocktower
[find-and-replace] Ensure a pattern without any path separators will be applied against only the filename rather than the entire path. @savetheclocktower
Bump our versions of atom-keymap and underscore-plus… including pointing all usages of underscore-plus to our new fork at @pulsar-edit/underscore-plus @savetheclocktower
Bump terminal to 0.3.2 @savetheclocktower
feat: Add editor.largeFileThreshold config for TextMate large file mode @asiloisad
Cirrus: Update Rolling release token @DeeDeeG
Resolve keyBindingCommand tooltip label lazily instead of at registration time @asiloisad
fix: clamp cursor column during rendering to prevent display at invalid positions @asiloisad
Hide empty file-info element in status bar @asiloisad
Honor activatePane: false when workspace.open split creates a new pane @asiloisad
Fix language-gfm setext header symbol queries @bwanders
Cirrus: bump node from v16 to v20 @DeeDeeG
Fix keyBindingCommand breaking function-based tooltip titles @asiloisad
[find-and-replace] Fix project search regression when searching modified buffers. @savetheclocktower
Guard against a user saving while the text buffer is conflicted by alerting them to the problem and giving them a choice between cancelling and overwriting the contents on disk. @savetheclocktower
Chore: Restore org templates to repo @Daeraxa
CI: Bump 'nick-fields/retry' to v4.0.0 (exact SHA) due to Node 20 Actions deprecation @DeeDeeG
Add the new terminal package to core @savetheclocktower
[ci] Run Package tests more appropriately @confused-Techie
Use SHA256 Digest for RPM Build @ChrisLeinbach
fix(deps): update dependency temp to ^0.9.0 renovate (bot)
chore(deps): update dependency temp to ^0.9.0 renovate (bot)
chore(deps): update dependency temp to ^0.9.0 renovate (bot)
chore(deps): update actions/upload-artifact action to v7 renovate (bot)
chore(deps): update actions/checkout action to v6 renovate (bot)
chore(deps): update actions/cache action to v5 renovate (bot)
fix(deps): update dependency minimatch to v3.1.4 [security] renovate (bot)
chore(deps): update dependency dompurify to v3.3.2 [security] renovate (bot)
[exception-reporting] Remove core package @confused-Techie
Improve "Project does not exist" popup @kiskoza
Bump Electron version to v30.5.1 @DeeDeeG
Change timing of window focus when a new project is opened @savetheclocktower
Ensure NodeJS version matches what we actually use @confused-Techie
[build] Check Windows version during install @confused-Techie
Fix crashes in measureHorizontalPositions and updateBlockDecorations for non-rendered rows @asiloisad
[archive-view] Bump ls-archive => @pulsar-edit/ls-archive @confused-Techie
[autocomplete-plus] Allow matching suggestions to stay in the list after filtering… even if the first character of the suggestion does not match the first character of what the user typed. @savetheclocktower
Remove unmaintained Dockerfile @DeeDeeG
Tree-sitter rolling fixes, 1.132 edition @savetheclocktower

@pulsar-edit/atom-keymap

feat: add CmdOrCtrl modifier alias for cross-platform keybindings @asiloisad
Remove reference to old package in readme @Daeraxa

@pulsar-edit/fuzzy-native

Explicitly include cstdint to make GCC happy @savetheclocktower

@pulsar-edit/ls-archive

PR from before Pulsar's fork:
- Support bzip2 @YtvwlD
PRs since Pulsar's fork began:
- Adds Testing GH Actions @confused-Techie
- Rebrand Repository @confused-Techie
- Manual decaf source @confused-Techie
- Manual decaf specs @confused-Techie
- Get tests to run w/ our latest version of NodeJS @confused-Techie
- Bump almost all dependencies @confused-Techie
- Bump tar dependency @confused-Techie
- Make this repository publishable to NPM @confused-Techie

@pulsar-edit/text-buffer

Fix incorrect isInConflict logic @savetheclocktower

terminal

New package by @savetheclocktower; “Uses XTerm.js and node-pty.” “Based heavily on atomic-terminal, x-terminal-reloaded, and all their predecessors.”
- See package README for details
Fixes terminal:set-selection-as-find-pattern keybind @Daeraxa
Fix context menu commands @Daeraxa
Fix: update keymap selector to work correctly on linux @Daeraxa

@pulsar-edit/underscore-plus

PRs from before Pulsar's fork:
- Only decaffeinate @aminya
- Migrate to Github actions @darangi
PRs since Pulsar's fork began:
- Add cmdorctrl to modifier key maps @asiloisad
- Update all GHA @confused-Techie
- Manually define a default export in order to play better with transpiled code in the Pulsar codebase. @savetheclocktower
- Opt into "loose" mode for transpiling to CommonJS so that the exports can be mocked in specs. @savetheclocktower

ppm

Bump bundled Node to 20.16.0, to sync with Electron 30.5.1 in Pulsar core repo @DeeDeeG

Better late than never: the new terminal package

2026-05-10T00:00:00Z

In advance of the release of Pulsar 1.132.0, I’m thrilled to announce that Pulsar now has a built-in terminal package — removing one of the biggest headaches for new users.

Motivations

Why a built-in terminal package, and why now? After all, we try to keep the core Pulsar experience lean. For years, Atom and Pulsar users who’ve wanted an integrated terminal have had to install a community package. What’s changed?

In short:

Lots of users want an integrated terminal.
They’re hard to install for most users in a way that most community packages aren’t.
Bundling a terminal package therefore removes a major headache for new users and should vastly improve their day-one experience.

Lots of people use a terminal package

Every new core package adds weight to the Pulsar bundle. The best way for the new package to justify that extra weight is to deliver functionality that many users expect to be present.

And, indeed, questions about installing terminal packages are among the most common requests in our support channels. I’ve got no doubt that a core terminal package was frequently requested back in the Atom days; platformio-ide-terminal is, after all, the most popular community package of all time.

Many of our new users come over to us after having used Visual Studio Code, whose own built-in terminal likely influences their habits and expectations.

Ordinarily, even popularity wouldn’t be a magic bullet. One of our justifications for keeping the core so lean is the idea that anything that isn’t in the core takes only a few extra clicks to install. Yet…

It’s hard to install

Terminal packages in Pulsar are notoriously hard to install. That’s because they can’t be written in JavaScript alone! They require a library that supplies a pty, or pseudoterminal, in order to do terminal emulation — in this case, node-pty. And such libraries need to bridge to system-specific APIs.

A Node package that includes code written in a lower-level language — typically C++ — is usually called a native addon. If you want to install a Pulsar package with a dependency on a native addon (like node-pty), you’ve typically got to compile that addon for your own machine. That requires a C++ toolchain to be installed on your computer.

Whether that toolchain is already present depends on your operating system and the sort of software development you do. But no matter the platform, I’d bet that most users probably fail at installing a package like x-terminal-reloaded on the first attempt. And no matter how detailed our documentation is on the topic, there’s a limit to how user-friendly we can make this process. I’ve seen users give up on Pulsar at this early stage.

Most community packages don’t rely on native addons! How bad is our luck that one of the small handful of such packages is the one that new users most want to install on their first day of using Pulsar?

This affects the bundle-or-don’t-bundle calculus, to say the least. Bundling a terminal package bypasses all of these headaches! The needed compilation would happen at the same time that it happens for any other native modules used in Pulsar: when we build binaries for each operating system and processor architecture.

It also saves the user from having to roam around a graveyard of community terminal packages in our package registry, trying to figure out which one still works. Which reminds me…

It’s hard to keep community terminal packages working

We go through terminal packages faster than Spinal Tap goes through drummers! When users have asked which terminal package they should install, we’ve always recommended x-terminal-reloaded: it’s been maintained by Pulsar team member @Spiker985 for a few years, was known to work in Pulsar on all platforms, and was a strong candidate for addition to core in its own right. Yet x-terminal-reloaded is a fork of x-terminal, which was a fork of atom-xterm, which was a fork of term3, which was a fork of term2, which was a fork of term.

Maybe the maintainers of these packages all just happened to have very short attention spans. But I think it’s far more likely that terminal packages needed time and attention to keep up to date, especially in the early days of Atom and Node.

To illustrate, we need only look at the recent Electron modernization and the pains it caused. Like lots of other packages with native module dependencies, x-terminal-reloaded was affected by the upgrade from Electron 12 to Electron 30 — and to keep it working on newer Pulsar versions was a technical problem without an easy solution.

In short: node-pty now uses a multithreaded model on Windows to get around a deadlock issue. But this requires using Node’s worker_threads library — and Electron doesn’t support that library in the renderer process, which is the context where community packages execute code. So right now x-terminal-reloaded works just fine on macOS and Linux, but fails to spawn a terminal on Windows. This leaves Windows users with no working community terminal packages.

This, in fact, was the last straw. It could’ve been worked around with a major architectural change in x-terminal-reloaded — but it made much more sense to spend that effort on bringing a new terminal package into the core. We didn’t want to let this opportunity go to waste.

Architecture

These were my goals for terminal:

Provide a simple, intuitive terminal integration that would suffice for at least 80% of users — while staying out of the way for those who don’t need it.
Make it work reliably and durably on all three of the operating systems we support.
Make it feel like a first-class part of Pulsar.

Features

The “easy” parts are the same across nearly all terminal packages: node-pty handles providing a pseudoterminal, and XTerm.js handles the rendering of terminal output.

I wanted to draw inspiration from community terminal packages, but I didn’t want a maximalist, power-user feature set! x-terminal-reloaded was the obvious place to start, so I studied that codebase for a while.

The long family tree from which it had descended meant that it had accumulated quite a few features over the years. I decided which ones were truly needed (theming, service integration) and which ones were overkill for most users (profiles). Then I started a new project and went to work.

It took me a while to realize that I was accidentally creating something very, very similar to the atom-community/terminal package, also known as atomic-terminal. When I started, I didn’t even realize this package existed. But it did see heavy development over a few years, and seemed to have similar goals around streamlining. It helped to confirm that I was moving in the right direction.

“Streamlined” doesn’t mean “minimalist,” though. I wanted terminal to have most of the features that users would expect. For instance, terminal supports text-searching in terminal panes via the same keybindings you’re used to for editor text search — a feature that, to my knowledge, isn’t present in x-terminal-reloaded or any of its predecessors.

And if streamlining is your goal, unobtrusiveness is a feature in itself! One of the ways we earn the right to add a new core package is to ensure it doesn’t annoy anyone who doesn’t need it. All packages, even core packages, can be disabled; but if a user feels the need to disable a core package, it’s a sign that the package got in their way! I made sure that terminal didn’t have any impact on performance — like startup time — unless a user actually had a terminal open.

Durability

This package needed to work a bit differently than community terminal packages have ever worked before. I described above how a crucial dependency, node-pty, can no longer run in the context of an Electron renderer process. But that’s a solved problem: we can spawn a child process in a pure Node-only environment, then communicate with it via message-passing. All usage of node-pty happens in this isolated Node process. This is a common technique in community packages, and we’ll probably be using it more in Pulsar core in the future.

The strange constraints of Electron’s renderer process are not considered important enough for most Node library authors to accommodate. We rely quite a bit on libraries like superstring and pathwatcher that have native addons — but, crucially, the Atom folks wrote those libraries, and we maintain them. If they suddenly needed changes in order to continue working properly in the renderer process, we’d make those changes!

By contrast, node-pty is maintained by Microsoft, and they have no particular motivation to ensure it continues to work under the conditions we need.

So even though this worker-process architecture is only strictly needed for Windows, we’re using it on every platform. The downsides are minimal, whereas the future pain we might be avoiding is substantial. By adding terminal to core, we’re committing to its ongoing maintenance, so we want to build a durable, future-proof foundation.

Integration with Pulsar

All packages should ideally feel like they’re part of Pulsar — but core packages especially! This will be an ongoing effort, but a few aspects required particular attention.

Styles

One way to make terminal feel like it belongs is to ensure that the terminal’s own colors match the colors of the user’s syntax theme.

Terminals follow the ANSI standard for four-bit colors: eight “regular” colors (which include black and white), plus eight “bold” variants of those colors.

Any syntax theme created from this point forward will be able to define terminal colors explicitly, with the expectation that the shades of red, blue, green, and the rest will match similar shades already being used by the theme.

But, of course, lots of you folks stick with a built-in theme! So we’ve made sure those eight built-in syntax themes specify their own terminal colors.

If you happen to use a theme that doesn’t define these colors, we’ll still be able to infer some values from your syntax theme, and use sensible fallbacks for the rest. You’ll be able to customize or replace the colors you see in the terminal via either package configuration or stylesheet overrides.

Keybindings

Community terminal packages have tended to register lots of commands and lots of associated keystrokes. But it’s already hard to find unused keybindings! I felt that a new core package should go out of its way not to be pushy here. This helps check the “unobtrusiveness” box: any new keybinding we introduce is something that might already be used by a community package, and I don’t want to disrupt anyone’s muscle memory.

That’s why most of the terminal package’s commands operate on key sequences. The main function (show me a terminal, or spawn one if none exists) gets a simple and memorable key binding at Ctrl+`, but nearly all other commands are a sequence of two different keystrokes.

For instance: there are separate commands for opening a terminal in various “directions.” You might want to open a terminal to the right of the current editor, splitting the pane container. A key sequence makes this easy to remember, and harmonizes with existing key sequences for similar tasks; we can bind this command to Ctrl+~ →. If you want to open the new terminal in a different direction, you can simply use a different arrow key; Ctrl+~ ← will split the pane container and open a terminal to the left rather than the right. This matches similar key sequences already present in Pulsar for splitting panes and moving cursor focus between pane items.

All the terminal key sequences, in fact, can be started with the same key binding: Ctrl+~ (i.e., Ctrl+Shift+` if you’re using a US QWERTY keyboard).

The downside to this approach is that, on non-US keyboard layouts, some of these bindings will wind up on unexpected keys! The ` and ~ glyphs live together in the US, but often split up and do their own thing when they travel abroad. Ideally, we’d always target the key just above Tab and to the left of 1, regardless of which characters are assigned to that key in a given layout. We have a plan to make this possible, but it’ll take a bit of gruntwork.

In the meantime, if you don’t like the keybindings we chose, you can can remap them the same way you’d customize any other keybindings.

Help us test it!

As I mentioned, the status quo on Windows (no known working terminal packages since 1.131.0!) made this an urgent package to get into core. This package is ready to use, but it is nowhere near feature-complete, and we’d love to get some feedback from users. So please put it through its paces and report any bugs you find.

A few users helped us with beta testing — and special thanks to @Daeraxa for doing some intensive QA work in the last couple weeks! — but experience has told us that the best way to get testers is to ship code in the regular release. You may consider this package “experimental” in that it’s not seen much real-world usage yet, but make no mistake — it’s here to stay.

If you don’t like the new terminal package, you can keep using x-terminal-reloaded if you’re on macOS or Linux. Windows users don’t have a working alternative yet, but we’d be happy to give some guidance if you wanted to build a power-user, feature-stuffed community terminal package that works across all three of the platforms we support.

In the meantime, we’re excited to be shipping this feature, since it’s probably the most meaningful change we can make toward improving the “out-of-box” experience for a new Pulsar user. We’ve got ideas for deeper integration between the terminal and the rest of Pulsar and plan to tackle them over time. Happy coding to all you spacefarers, and enjoy the new toys on board!

Pulsar v1.131.0: A Valentine's Day & Electron 30 Edition

2026-02-15T00:00:00Z

Pulsar 1.131.0 is available now!

Pulsar v1.131.0: A Valentine's Day & Electron 30 Edition

Hello, and welcome, one and all! This release brings the long-awaited (and long-previewed in our Rolling releases) upgrade to Electron 30 to our stable "Regular" releases!

Catching up, at least somewhat, with the rapid pace of new Electron versions is a goal we've been actively working on since we started Pulsar almost 4 years ago. We're happy to make one of the larger steps in that direction since we began with this release (from Electron 12 to Electron 30.) We recognize that Electron 30 is still not the latest Electron version, but it took a tremendous amount of work to get here, and we are still working diligently on further upgrades.

On a more business-as-usual note, we also have several language/grammar improvements, various bugfixes and miscellaneous improvements. Please see the full changelog below for details.

We're very excited for this milestone, and please do let us know if anything needs fixing -- this was a huge undertaking under the hood! (Did we mention the accompanying blog post?: https://blog.pulsar-edit.dev/posts/20251202-savetheclocktower-pulsar-on-electron-30/)

As always, a huge thank you to our community, contributors, and donations. Happy coding, and see you amongst the stars! - The Pulsar Team

1.131.0

Because this is such a huge upgrade to Pulsar, some of your community packages may be affected! If you handle distributions for Pulsar as a community maintainer make sure to read this changelog carefully to make things compatible! For more information, read Pulsar on Electron 30: what it means for you.

Update Electron to version 30!
- Node is now version 20.11.1
- Chromium is now version 124
- This means better performance, better Node library compatibility, and ability for community packages to use newer features of Chromium.
- It should also vastly improve the Pulsar experience for Linux users in Wayland environments.
- Because this is such a big upgrade, some of your community packages might be affected!
Bump ppm to use Node 20.11.1
- For the first time in a long time, both ppm and Pulsar are using the same version of Node; this should avoid some rare bugs encountered when installing certain packages.
Fix handling when opening files to certain line numbers via CLI - e.g. pulsar foo.txt:30.
Prevent packages from spawning new background tasks if the environment is unloading (as would happen during a window reload or while quitting Pulsar).
[find-and-replace] Fix an issue where certain files would show results in a project-wide search even when they would be excluded by the file/directory pattern.
[markdown-preview] Fix situations where "Save as HTML" and "Copy as HTML" silently failed with certain kinds of content.
[autocomplete-plus] Prevent certain kinds of suggestions from being incorrectly filtered out of the result set.
[language-java] Update to the latest tree-sitter-java parser, adding support for multiline strings, among other things.
[language-python] Better highlighting of except clauses; fixed folding of certain if blocks.
[language-typescript] Better highlighting of template literals; adding folding of interface and enum blocks.
[language-javascript] Proper highlighting of JSX with namespaced attributes.

Pulsar

Enhance documentation for atom.commands.dispatch() method @trusktr
Fix autocomplete-plus crash with non-workspace editors @asiloisad
Fix tree-view crash when dock pane is split @asiloisad
Tree-sitter rolling fixes, 1.131.0 edition @savetheclocktower
Always show suggestions with textEdits instead of filtering them out @savetheclocktower
Fix incorrect interpretation of a line-number spec on the command line @savetheclocktower
Prevent task spawning during unload @savetheclocktower
[markdown-preview] Fix failure to serialize to HTML when the document contains certain kinds of code blocks @savetheclocktower
Bump to latest ppm after fixing the force-process-config issue in ppm#162 @savetheclocktower
Remove reliance on title key of a setting to avoid using locale labels @confused-Techie
Bump CI runners to macos-14 @savetheclocktower
Fix text-editor-component annoying bug @Psychosynthesis
Migrate to python3 style super for new class snippets in language-python @bridgetjs
Update to Electron 30 @mauricioszabo and @savetheclocktower
Cirrus: Update Rolling upload token @DeeDeeG
[find-and-replace] Prevent addition of project results from editors whose paths are not matched by the current path inclusions @savetheclocktower
Tree-sitter rolling fixes, 1.130.0 edition @savetheclocktower
Update actions/setup-python action to v6 @renovate
Update actions/setup-node action to v6 @renovate
[meta] Add new and missing packages to our renovate config @confused-Techie
Update pulsar-updater package @renovate
Update actions/checkout action to v5 @renovate
Add "Regular Release Checklist" issue template @DeeDeeG

Changes for Electron 30

Internals of 'Update to Electron 30' PR

Remove all support for legacy Tree-sitter
Prefer @electron/remote, deprecate direct usage of electron.remote and switch all internal usages to @electron/remote.
Decaffeinate tree-view
Fix a failing autocomplete-plus spec
Get dev-live-reload specs passing
Get image-view specs passing
[language-ruby] Add a basic grammar test spec
[markdown-preview] Get specs passing
[settings-view] Get specs passing
Point to Electron 30.0.9 and point our dependencies to the NPM-published versions under the @pulsar-edit namespace that are compatible with Electron 30.0.9.
Fix some TextEditorComponent issues related to changes in Chromium sometime between Electron 12 and Electron 30.
Eliminate reliance on typescript-simple in favor of a custom solution that uses the typescript package directly.
Consume get-scrollbar-style to replace the deprecated scrollbar-style module
Additional changes related to device pixel ratio that probably should have gone in the earlier commit.
Add the ability to report crashes via Electron's standard crashReporter interface.
Delete deprecated "app.allowRendererProcessReuse = false"
Enable @electron-remote for the given window during startup and disable a Blink experimental feature that was causing trouble with package compatibility (because it added an on method to all DOM nodes!).
Be more paranoid about release channels in a handful of places in case we want to maintain a next (or nightly or preview) release channel on an ongoing basis.
Cache Language instances in web-tree-sitter so that the specs don't run out of memory.
Preserve an ATOM_CHANNEL environment variable if it exists and other changes related to release-channel agnosticism.
[snippets] Get specs passing
[spell-check] Get specs passing and abandon atom-pathspec in favor of an internal implementation.
[tabs] Fix an exception that can happen in unusual scenarios when the browser can't give us an element under a given X/Y coordinate.
[update-package-dependencies] Get specs passing
[symbol-provider-tree-sitter] Unmock clock in the standard way
Remove outdated Tree-sitter documentation
Update GitHub Actions CI jobs to include Wayland-related keyboard dependencies.
Update CirrusCI build job to include Wayland-related keyboard dependencies.
Revert to a single entitlements.plist now that we're no longer affected by the awful libuv bug that was present in Electron 12.
Update script/electron-builder.js to support a couple of command-line switches and to build correctly for Electron 30.
Fix ThemeManager specs
Define two methods on the atom global to work around tree-view issues related to trashing and revealing items in electron.shell.
Comment reformatting
Some integration test fixes
Fix PackageManager specs
Use yarn.lock from updated-latest-electron branch
Swallow exceptions raised by pending tests
Disallow if( and the like in .eslitrc
Add submodules: true back into certain workflows
Remove atom.trashItem and atom.showItemInFolder since they weren't even being used. The equivalent functions from the shell module of @electron/remote have been performing the same task in PulsarNext for a while now.
Update ppm to commit d288b0978b35f7c0ffb3dc5c1e50c
Update ppm to commit 07faba10096ee4239ce671218d9953fb2e40ecbf
Remove unnecessary Promise.all

ppm

Fix CI @DeeDeeG
Fix misnamed variable in rebuild command @savetheclocktower
Upgrade Node to version 20.11.1 @savetheclocktower
Add TypeScript template @savetheclocktower
Revert setting of --force-process-config now that we’re on Electron 30 @savetheclocktower

Pulsar on Electron 30: what it means for you

2025-12-02T00:00:00Z

If you’re reading this, Pulsar’s long-planned upgrade to Electron 30 is finally upon us. This applies to rolling releases on or after December 2 and to regular release versions 1.131.0 and later.

We expect that lots of users will experience no downside to this upgrade whatsoever. But some community packages might need updates to work with Electron 30, so please read on to find out how this release could affect you!

A few months ago, I laid out what it means whenever we upgrade Electron to a newer version:

code runs in a newer Chromium environment and can take advantage of newer web features;
code runs in a newer Node environment (in this case, version 20 instead of version 14!) and can take advantage of newer Node features; and
perhaps most importantly, you may notice substantial improvements in performance.

But this upgrade brings us from Electron 12 to Electron 30, so it’s a bigger change than usual. If you want, you can go back through old blog posts to learn why this was a challenging upgrade from our perspective. But here’s how it may affect you as a user:

(Optionally) back up your home folder

We’ve tested this upgrade both with a clean home folder (the folder named .pulsar that holds your settings and packages, among other things) and with a pre-existing home folder, and both have worked just fine in our tests.

That said, if you’re still nervous about this upgrade, do one thing before you proceed with anything else: back up your home folder. It’s dead-simple to do and acts as the ultimate “abort” button: in the unlikely event of something going haywire, restoring the previous state is as simple as replacing your Pulsar home folder with the backup.

By default, your home folder lives at ~/.pulsar on macOS/Linux and %USERPROFILE%\.pulsar on Windows. You can also open a file explorer window at the root of your home folder by opening the settings and clicking the Open Config Folder button at the bottom of the sidebar; that should identify your home folder correctly even if it’s different from the default.

If you don’t already have a more comprehensive backup strategy for all your system data, consider at least creating a compressed backup of your home folder once in a while just so you can preserve the exact state of things — temporary/unsaved files, the module compilation cache, and so on.

Handle possible package incompatibilities

After you upgrade, you might see the icon above in your status bar. It’s put there by the core incompatible-packages package, whose job is exactly what it sounds like: detecting packages that are incompatible with the current version of Pulsar.

The only packages that may be flagged after this upgrade are packages that use Node libraries with native module bindings. It’s not worth doing a deep dive into what that means… but if you had to consult this documentation page when installing a community package, it’s likely to be affected by this upgrade.

If you see the icon above, click on it to read details about the incompatibility. You can expect one of several messages to be shown, but most commonly:

The message may suggest that a library needs to be recompiled for the newer version of Electron. If the Rebuild Packages button is enabled, click it; when it’s done rebuilding, you can reload your window (or relaunch Pulsar) to see if that fixed the incompatibility. If you no longer see the “bug” icon in your status bar, you’re probably good to go.
If it says something about “use of non-context-aware module in renderer,” that’s a bigger problem that requires a bigger fix. If this happens to you, please report it in this megathread and we’ll figure out what we can do about it. Odds are good we’ll be able to fork the package and deliver a working version, or else point you to a similar package that does the same thing.

Known packages with issues

Of the packages that are known to be affected, the most common are hydrogen and x-terminal-reloaded:

hydrogen depends on an old version of zeromq that does not work in newer Electron.

The bad news is that the hydrogen package is no longer maintained by its original authors; the good news is that @asiloisad, our prolific community package contributor, has built a fork called hydrogen-next that ought to be a drop-in replacement.
x-terminal-reloaded is the only actively maintained terminal package (for now!) and is relied on by many to provide a built-in terminal. It once relied on a very old version of the node-pty package that was incompatible with newer Electron.

The good news is that we anticipated this a while back and worked with @Spiker985 (maintainer of x-terminal-reloaded) to update to a newer node-pty version; macOS and Linux users should experience no issues with this package as long as it’s up to date.

The bad news is that Windows users will likely run into another issue. We’ve got a potential fix for this issue in the works, and if you know your way around the Node ecosystem and are a Windows user, we could use your help testing it!

The better news is that Pulsar users will soon have a much simpler option for a cross-platform terminal package, but you’ll have to wait just a bit longer for that announcement.

Other issues

I’ve been running some version of Pulsar on Electron 30 for more than a year, and at least a dozen other users have been beta-testing it for months. That said, if you run into problems that aren’t covered above, please report them in the megathread and we’ll get to the bottom of it.

Remember that you can always revert to earlier versions of Pulsar via the GitHub releases page.

What’s next?

Finally delivering this upgrade is a big load off our backs, but the job’s not done. We picked Electron 30 last year just to have a target to fixate on, but Electron’s already up to version 39! So you can expect us to gradually play catch-up over the next few releases.

Luckily, future Electron upgrades should be nowhere near as disruptive as this one. The worst thing about it is that catching up to Electron 39 will drop official support for some older operating systems:

Electron 33 drops support for macOS 10.15 (Catalina).
Electron 38 drops support for macOS 11 (Big Sur).

In addition to this, Electron 23 has already dropped support for Windows 7, 8, and 8.1.

We regret this, but Electron apps are beholden to Chromium’s support matrix. If Chromium drops support for an operating system, it’s dropped. If this will affect you, you’ll at least be able to use older versions of Pulsar indefinitely. If it affects enough people, we might explore a custom release channel of Pulsar that tries to deliver new features while maintaining a broadly compatible Electron version. (No promises!)

But that’ll all come into focus in the future. For now, happy coding, and see you amongst the stars!

Pulsar v1.130.1: Hotfix for Windows

2025-10-09T00:00:00Z

Pulsar 1.130.1 is available now, fixing the broken Windows release of v1.130.0.

Pulsar v1.130.1: Hotfix for Windows

Hotfix: Restore Windows app to working condition, after it was mis-built in v1.130.0.

Description of the issue affecting v1.130.0 on Windows: The Windows version of the app was broken, due to its native C/C++ dependencies remaining built for NodeJS when electron-rebuild failed, and due to our CI being mistakenly configured in a way that hid the failure. Electron-rebuild failed in CI due to a missing Windows 10 SDK.

Resolution: We have worked around the missing Windows 10 SDK issue in CI by installing it manually, and also updated our CI workflow so that a failure of electron-rebuild would be more likely to be caught.

Note: Binaries for macOS and Linux are also provided to make it simple to find the latest binaries for all platforms attached to one GitHub Release. Other than coming from a new CI run with a new patch version bump, there should be no other changes from v1.130.0 on macOS or Linux.

Thank you very much to our community members for quickly reporting this issue and helping to confirm the fix.

As always, a huge thank you to our community, contributors, and donations. Happy coding, and see you amongst the stars! - The Pulsar Team

1.130.1

Fixed broken Windows build that affected Pulsar v1.130.0
Updated our CI to not miss this particular type of build failure, should it occur again

Pulsar

[ci] Fix Windows Builds by manually installing the Win10 SDK @confused-Techie
CI: Split 'yarn build' and 'yarn build:apm' into separate steps @DeeDeeG

Pulsar v1.130.0: Spooktacular Edition

2025-10-09T00:00:00Z

Pulsar 1.130.0 is available now!

Pulsar v1.130.0: Spooktacular Edition

Welcome to another Spooktacular Pulsar release!

To welcome in the Autumn, we'd like to shout out some updates to our website!

The long awaited revamp of our web presence not only massively improves and updates our documentation, it also unifies our web design. There are new subdomains for each service, and we've put our hugely improved documentation live (which you may have seen during its beta period). It's now more in-depth and updated, and it's finally got auto-updating API docs for Pulsar, which we have been missing since the beginning.

As for the Pulsar editor itself, we've got some updated Tree-sitter and language support, as well as autocomplete-css and autocomplete-plus updates and improvements, a focus fix for tree-view on Windows, a fix so that find-in-project searches properly exclude open-and-modified files that don't match the given path filter, and a change to snippets to restore legacy compatibility with the emmet package.

A new "I18n" API (short for "internationalization") allows Pulsar and even community packages to localize all their text to a user's preferred language. It's in its very early stages, but after some more time and work you should be able to set your preferred language and have Pulsar respect it.

As always, a huge thank you to our community, contributors, and donations. Happy coding, and see you amongst the stars! - The Pulsar Team

1.130.0

autocomplete-plus can now make other text edits to the buffer when a suggestion is accepted - for instance, adding an import for that suggestion.
Experimental localization support is now being added into the editor, allowing the editor, core packages and even community packages to localize their interface for any language.
autocomplete-css has gotten significantly updated completions.
Various documentation and UI links updated after website update.
Changed some returns in a backwards compatible way to ensure the community package emmet will work again.

Pulsar

[find-and-replace] When a path pattern is provided on a project-wide search, Pulsar won't include any open and modified buffers in the search unless their paths also match the given pattern. @savetheclocktower
[autocomplete-plus] Add support for "additional" text edits when a suggestion is accepted @savetheclocktower
Cirrus: Update Rolling Release binary upload token @DeeDeeG
update-manager-spec.js - release notes url spec change @wesinator
[snippets] Add getter to fix emmet package @savetheclocktower
Update dependency minimatch to v3 [SECURITY] @renovate
[tree-view] Ensure Explorer opens in focus on Windows @confused-Techie
[core] i18n: Fresh Start @confused-Techie
[autocomplete-css] Update Completions, deps, improve completions data sources @confused-Techie
Resolve Issues in packaged Pulsar Localization @confused-Techie
[meta] remove legacy atom project md files @wesinator
Update keymap documentation links @williamtheaker
[core & timecop] Locale loading Statistics @confused-Techie
Cirrus: Pin fpm gem to ~> 1.16.0 @DeeDeeG
Ensure watchPath "de-normalizes" filesystem event paths if opted into so that users of watchPath don't have to do their own realpath resolution @savetheclocktower

Pulsar v1.129.0: An August Occasion

2025-08-07T00:00:00Z

Pulsar 1.129.0 is available now!

Pulsar v1.129.0: An August Occasion

Howdy folks,

Another fine Pulsar release, Pulsar 1.129.0, is available for your use and enjoyment. See changelog below for details.

A big shout-out to @Drsheppard01 for their first contribution in the form of PR #1241, and to @jmanuel1 for the issue report #1302 that led to a quick fix from @savetheclocktower in PR #1303. And to several members of the community who have given feedback on GitHub, Discord, etc.

As always, a huge thank you to our community, contributors, and donations. Happy coding, and see you amongst the stars! - The Pulsar Team

1.129.0

Some minor Tree-sitter fixes, including fixing a bug in SCSS highlighting and ensuring proper highlighting support for abstract methods in TypeScript.
When viewing a file that exists on disk outside of your project root, you may now use Tree View: Rename to “import” it into your project folder by giving it a relative path.
Updated various dependencies for security reasons.
Updated AppImages to type 2 runtime -- libfuse is no-longer required to be installed on the end-user's system to use Pulsar's AppImages!

Pulsar

Cirrus: Fetch Buster packages from archive.debian.org @DeeDeeG
Update deps June 2025 @DeeDeeG
Update appimagetool link in ./scripts/fix-linux-appimage.sh @ Drsheppard01
Tree-sitter rolling fixes, 1.129 edition @savetheclocktower
Fix CI build job in Ubuntu @savetheclocktower
[tree-view] Allow tree-view:rename to "import" the current file… @savetheclocktower
Cirrus: Update Rolling upload token @DeeDeeG
Refactor StateStore to remove dependency on the atom global @savetheclocktower

Pulsar on modern Electron: clearing the runway for arrival

2025-06-30T00:00:00Z

You might’ve noticed that the releases around here have been getting sparser and sparser. We haven’t even had a release since May. Is this the dreaded death spiral?

No, it isn’t; we’ve just entered the cocoon and are preparing to emerge as a more modern and performant butterfly. And you can help us test that butterfly!

We’re getting very close to releasing the biggest update to Pulsar that there’s ever been: making it run on a recent version of Electron, the framework that allows us to write HTML and CSS and JavaScript and turn it into a desktop application. Our current version of Electron is almost four years old, so this is a major upgrade.

When it happens, we think you’ll all notice the difference; for one thing, startup speed should be much faster for everyone. But for some users it might be disruptive, so we’re pre-announcing its arrival so we can set expectations and help folks understand how they might be affected. One way you can guard against this is to download the new version and help us test it!

But I’m getting ahead of myself. Let’s do this FAQ-style.

Why haven’t there been regular monthy releases lately?

We’re all volunteers who often have to juggle other things in our lives. Pulsar always shot for a once-a-month release schedule — ideally around the 15th, but often a few days late!

In recent months, however, there simply haven’t been as many things to ship. The most recent version, 1.128.0, was larger than usual — RTL text editing, new highlighting options for comments in JSON, and a couple of big performance improvements. Since then, though, there haven’t even been enough changes to the main Pulsar branch to make a new release a priority.

But why? We certainly haven’t run out of things to address.

I can’t speak for others, but I know the answer for myself: about 80% of my Pulsar-related efforts in this calendar year have been spent on the boring but important goal of Electron modernization.

Why does Electron need to be updated?

Electron is based on Chromium, the open-source flavor of Google Chrome. Chromium updates on a regular basis for all the reasons that a browser needs to update: new features, architectural improvements, performance improvements to V8 (Chromium’s JavaScript engine, and also the engine that powers Node), and security fixes.

For those reasons, it’s important for Electron to update at a similar cadence to Chromium so that it can also enjoy those features and security fixes.

Electron also bundles Node, so each release includes whatever version of Node is stable at time of release. This is important because Electron isn’t very useful if it’s using a version of Node that’s too old to support the requirements of commonly used NPM packages.

Why is Pulsar’s Electron version so far behind?

Atom literally invented Electron; and, as we learned with Tree-sitter, it’s sometimes expensive to be the first implementer of a major new thing.

We’ve written before about our goal to get Pulsar onto a modern version of Electron. We’re on version 12.2.3 right now — positively ancient considering that the stable version at publish time is 36.4.0. Version 12.2.3 dates back to November of 2021.

Atom was on an even older version of Electron, and one of the early goals of the Pulsar team was to modernize the editor in all respects, including its Electron version. When it was upgraded to 12.2.3, though, that wasn’t even the newest version of Electron at the time — it was just as far as it could be upgraded without major changes to the codebase.

What changes had to be made, and why?

One of the biggest tasks on that list — maybe as big as all the others combined — was retiring the original implementation of Tree-sitter and replacing it with a modern implementation using WebAssembly. (And if that’s news to you, I have a seven-part blog post series for your perusal!)

As for the other changes and the why: I’d be happy to go into detail in future blog posts, but that’s too big of a topic for this one.

Why has it taken so long?

The changes we needed to make to Pulsar to upgrade Electron any further have loomed over us since the very beginning of Pulsar, like a list of chores that’s so long that you try to avoid even looking at it.

But you don’t have to look at the whole list at once; you just have to focus on the next task. And if you keep focusing on the next task in the list and only the next task, one day you’ll find yourself with a pretty short list. There used to be dozens of tasks on that list, and now there’s more like five. And it feels good.

Now, “slow and steady” is the moral of The Tortoise and the Hare, but I’ll bet the bystanders watching that race still got pretty bored! From starting the Tree-sitter modernization project to shipping it as the default, it took almost a year of my free time.

Some of the other tasks have been individually frustrating, but nowhere near as much of a time sink. But the sheer number of them means that we’re 2.5 years into Pulsar’s public existence and only now are we on the verge of delivering this upgrade we’ve known needed to happen since the get-go.

We wish it had happened faster! But it’s happening, and once it’s done we can move onto the next thing.

What will be different about this new version?

I’ll try to set expectations properly: it’s still going to feel like Pulsar. If you like Pulsar now, you’ll still like it after the Electron update. If there are major aspects of Pulsar you don’t like right now, I can’t imagine any of them will be substantially different after the update.

Except one: the new version of Pulsar really is quite fast to launch, and fast to open a new project window. Testers on all platforms have offered this feedback, often without our even telling them that they could expect an improvement in load times. For an editor that has a reputation (whether earned or unearned) of being sluggish, this is a big deal for us; and if that were the only improvement, it’d be plenty on its own.

Apple Silicon users in particular will be very happy to use Pulsar once the upgrade happens, as they are affected by an obscure performance bug that has been plaguing Pulsar since almost the beginning.

But also:

Newer Electron means newer Node. Electron 12.2.3 runs Node 14; Electron 30.0.9 runs Node 20. Node 14 has been in “end-of-life” mode for more than two years, and it’s an ongoing drag on Pulsar development and community package development. If you’re a package author, you might’ve already had situations where you had to use an older version of a dependency just to get it to run correctly in Pulsar.

I’ve felt this pain, too: pulsar-ide-css and pulsar-ide-json each run a language server in the background, but neither such server can be run in Node 14. Right now, a user has to configure each package with the path to a node binary on their computer so it can run the language servers in a recent version of Node.

It’s much simpler to have Electron spawn the language server itself using its own built-in version of Node. Once we upgrade Electron, this will once again be possible, and both these packages will become much simpler to use.
Newer Electron means newer Chromium. The web platform moves fast, and four years’ worth of improvements means things like:
- The :has() CSS pseudo-class that lets you identify elements by whether they contain other elements.
- Container queries will be especially nice to have in Pulsar. (For instance: certain pane items can exist either in a narrow side dock or the wide-but-short bottom dock. If they can be styled differently just based on the width of their containing element rather than the viewport, that’s a big deal.)
- The popover API is something we really should be investigating, too, since we use plenty of modal palettes in Pulsar. It might remove the need to do things like focus management in JavaScript and let them be handled by the browser itself.

These benefits are more immediately compelling to package authors, but users themselves will derive downstream benefits from anything that makes package development easier.

So, in short: you’ll be able to take advantage of performance improvements in Chromium and Electron, and will be able to write and use packages that rely on brand new web platform features.

And, of course, this upgrade wouldn’t be as meaningful if we planned to stay on 30.0.9 indefinitely. We’ve set that release as a fixed target for now, but future Electron upgrades will be much smoother.

What are the downsides?

There’s only one downside that comes to mind.

Just as Pulsar itself has had to update some of its packages to have them continue to work within Pulsar, some community packages might need to be updated in order to be compatible with Pulsar running on newer Electron.

Hardly any packages are affected by this, because it only matters for packages that have native bindings. But those packages tend to do big, important things.

One such example is x-terminal-reloaded, the most widely-used terminal package in Pulsar. Luckily, x-terminal-reloaded is maintained and has a straightforward upgrade path. We’ve been working hard to make a version of x-terminal-reloaded that works identically in both current Pulsar and future Pulsar so that you can upgrade without hassle.

Another example is hydrogen. In that case, the solution is more complicated, since hydrogen isn’t maintained anymore. But @asiloisad’s got a fork of hydrogen called hydrogen-next that uses newer libraries and ought to be a drop-in replacement.

Those are the major packages that are on our radar as needing updates. I’m sure there are others out there, and even if they’re obscure, I’d love to hear about them if they stop working. I’m quite confident we can guide you toward either a fix for the issue or a new package that does the same thing.

But, like I said, the vast majority of packages will keep working just as they are. I use about 60 community packages (not including the dozen or more that are under active development at any given time on my computer) and they all run equally well in new Pulsar as current Pulsar.

When will it be ready?

I speak both truthfully and unhelpfully when I say: it’ll be ready when it’s ready. I do think it’s a matter of months, but it depends on how quickly we can get through the last few chores on the list.

How can I speed it along?

Several ways. Let me arrange them in order of increasing likelihood:

Be the exact thing we need right now

If you’re a unicorn that loves Pulsar, has free time to contribute, and knows a lot about C++ and Node bindings… please reach out to us on Discord!

Contribute according to your expertise

More seriously, even if you don’t have that specific skillset, we can always use more contributors. If you know stuff about the web platform, you’d be useful, even if you don’t have specific experience with Electron. An eagerness to learn and participate is worth far more to us.

We could also use more redundancy on the devops side of the project. Pulsar requires a complicated CI workflow for automated testing and automated releases — three platforms, two processor architectures, and at least two “flavors” of release on each OS. If we had at least two people who were familiar enough with the CI flows to troubleshoot any issues that may arise during release, it’d be a lot easier for us to rotate into and out of the project as time permits.

If this sounds like your cup of tea, feel free to jump into the issue tracker or the list of open pull requests… or else ask on Discord if you’re eager to help but not sure exactly where to start.

Help us test PulsarNext

But we know even that’s a lot to ask. Lots of you already stare at screens all day for your jobs. But there is another option: if you’re willing to use beta software, you can help us test this new version of Pulsar.

Atom used to have a “nightly” release channel that could be installed alongside the regular version of Atom. In that spirit, we’ve got a “Pulsar on Electron 30” channel that you can install today; it’s called PulsarNext.

PulsarNext has been my “daily driver” for months and has been getting easier and easier to use over that time. But we need more beta testers on various platforms so that we can find and fix any remaining issues. The best way you can help us ship this new version of Pulsar is to be a diligent beta tester and file bug reports whenever you encounter bugs.

If this sounds interesting to you, keep reading!

How do I set up PulsarNext?

Download. We’ve got rolling releases set up for PulsarNext. Pick the appropriate release for your OS, architecture, and distribution method. But keep in mind that not every “release” has every possible version, since they’re built by different CI jobs. If you don’t see the one you need in a given release, keep looking through older releases until you find one.
Run. You can launch it from your GUI, as always. But if you launch it from the command line, keep in mind that its executable name is not pulsar; it’s pulsar-next. Likewise, for package tasks, instead of ppm you’ll want to use ppm-next (or pulsar-next -p).
Configure. For various reasons, PulsarNext does not share a configuration directory with Pulsar. But that means the two can coexist on the same system and can even be running at the same time, should you have a need to do so.

PulsarNext’s configuration lives in a directory called ~/.pulsar-next (on macOS and Linux) or %USERPROFILE%\.pulsar-next (on Windows).

To keep packages in sync between the two installations, you’ve got a few options:
- You can start from scratch and install packages manually.
- You can do a one-time copy of your packages from the packages sub-folder of your Pulsar home folder to the same path in your PulsarNext home folder.
- You can use a package like sync-settings; it works just as well for this use case as it would for two copies of Pulsar running on two separate machines. Just make sure to configure them with the same Gist ID and access token.
Use and/or test. Based on feedback, your initial experience with PulsarNext will probably be wholly positive.

If you do run into any difficulties, please tell us about them. Some examples:
- We had to rewrite one of our modules that monitors files and directories for changes. If you observe any symptoms that imply that file-watching isn’t working, please let us know. Examples might include the tree view failing to show files after they were created by something outside of PulsarNext, or the editor itself failing to update the contents of a file (when the buffer is unmodified) after an external tool changes the file’s contents.
- It should be rare, but if PulsarNext crashes outright, please let us know. (You’ll see a dialog titled “The editor has crashed” and options to close or reload.) On Windows and Linux, crash dumps will be generated within a special crashdump folder within your PulsarNext home folder. On macOS, you can find crash reports in Console.app under the “Crash Reports” sidebar heading. Please file an issue against Pulsar, attach your crash report or crash dump, and tell us what you were doing when it happened.
- If you’re a Linux user who uses a Wayland display server, please let us know if your keystroke detection isn’t working as expected — especially if you use a keyboard layout other than QWERTY. We had to implement this logic from scratch for Wayland users so that it worked just as well as it does for X users. Feedback so far has been positive, but we’d love to get more data points.
If you encounter bugs, you can file them as issues, or drop into Discord if you want to make sure what you’re seeing isn’t intended.

More to come

There’s a piece of advice I’ve sometimes heard: if you want to make sure you follow through with something, tell your friends you’re going to do it. It’s based on psychology; people don’t like to break commitments that they’ve made publicly.

Hence the purpose of this post isn’t just to ask for help; it’s to demonstrate a commitment to following through. We want to deliver this great upgrade as soon as we can, so we’re telling our friends about it — all of you, our loyal community of users.

As always, we’re grateful to you for your support — but especially for your patience through this long journey. Happy coding!

Pulsar v1.128.0: May There Be a Spring in Your Step!

2025-05-02T00:00:00Z

Pulsar 1.128.0 is available now!

Pulsar v1.128.0: May There Be a Spring in Your Step!

Hello, folks. Another month or so, another Pulsar release!

We've got performance improvements, an improved editing experience for RTL languages, and comment handling for JSON and JSONC files. Please also be aware this month's release contains a security fix, so do update when you can. Thank you to the reporter of this issue.

As always, a huge thank you to our community, contributors, and donations. Happy coding, and see you amongst the stars! - The Pulsar Team

Vastly improved support for right-to-left text editing — meaning languages like Arabic, Hebrew, and Farsi.
Added support for comments in JSON — both via a new grammar for .jsonc files and via a setting to enable comments in regular .json files.
Fixed performance issues that can arise when reopening a project with existing editor windows.
Updated DOMPurify. This is a security fix.

Pulsar

Tree-sitter rolling fixes, 1.128 edition @savetheclocktower
Cirrus: Pin macOS builds to using Sonoma images @DeeDeeG
Bump Ubuntu in CI to ubuntu-latest @savetheclocktower
Restore ability for packages to focus specs on both Jasmine 1 and Jasmine 2 test runners @savetheclocktower
[markdown-preview] Update dompurify to 2.5.7 @savetheclocktower
Create SECURITY.md @confused-Techie
Improve support for RTL text input @savetheclocktower
[find-and-replace] Fix some bugs in the spec suite @savetheclocktower

Pulsar v1.127.1 (Hotfix)

2025-03-29T00:00:00Z

Pulsar 1.127.1 is available now!

Pulsar v1.127.1 (Hotfix)

Here's a quick hotfix release, reverting a change that caused an issue for Linux users.

(For all other changes since v1.126.0, please see the release notes for v1.127.0.)

As always, a huge thank you to our community, contributors, and donations. Happy coding, and see you amongst the stars! - The Pulsar Team

Hotfix: Reverted a Wayland-related change that Linux users reported issues with on Electron 12.

Pulsar

Revert "Wayland pulsar script" @mauricioszabo