I love Sublime Text.

It's lightning-fast, elegant, and extensible with packages.

The problem: when updating packages, they often introduce other unwelcome updates to the local Packages/ directory. The updates might overwrite defaults, and can sometimes even erase my config settings. Sometimes updates introduce broken dependencies, causing the package to fail.

I can't risk the above. It disrupts my workflow.

Sublimis

So I decided to make a canonical, lifecycle-segmented monorepo - 'Sublimis'.

In the Sublimis repo, I fork and 'freeze' the crucial Sublime Text plugins that I deem feature-complete (even if the authors themselves don't think so).

I basically take ownership of each package so that:

• I don't have to rely on the whims of the package author.

• My environment remains immutable and predictable - I have mise en place.

• I can refactor and even add features to packages, under my version control.

The Architectural Philosophy: One-Way Flow

The problem with user-level plugin development/changes in Sublime Text is that it traditionally suffers from the "live edit" trap: making tweaks directly inside Packages/<PluginName>/.

I decided to do away with this. I took 3 distinct approaches:

1. One-way package deployment I've set myself to a strict invariant:

   Repository → Sublime Text.
   
   Never Sublime Text → Repository.
   

   Thus my 'Sublimis' repo now becomes the single source of truth for specific deployed packages. So it doesn't matter how cluttered or modified the /Packages folder becomes.

2. Managed replacement deployment: The live Sublime Text Packages/ directory is treated purely as a build/deployment target. Nothing gets edited there. Instead, package folders are entirely replaced if edits are done to the source Sublimis repo.

3. Lifecycle-segmented monorepo

   My Sublimis repository is now organized around lifecycle states.

   • wip/ - Incubator for first-party (my own) plugins that are under active design/development.

   • staging/ - Ingesting and study area for third-party packages.

   • deployed/ - Production-ready plugins approved for day-to-day deployment.

   • archived/ - Cold storage. For historical reference, and sunset projects.

Starting Small

For today, I've done up three packages/projects:

1. Variants of dark and light themes (as a personal offshoot off Dracula).

2. SublimisTasks, which I forked from PlainTasks.

3. SublimisGremlins - which removes gremlins (Unicode/invisible characters and anomalies, zero-width spaces, etc) from the editor, and is a surprisingly useful plugin (since gremlins can sometimes break builds and cause maddening debugging sessions).

I think Sublimis captures a useful philosophy. That once I deem something open-source as 'done' and feature-complete, then I should make it my own.