zed-industries/extensions: a central registry for Zed

zed-industries/extensions and the extension contribution problem

zed-industries/extensions solves a distribution and coordination problem for the Zed editor. The README describes it as the central repository containing extensions available for Zed. Its principal users are contributors who want to submit a language extension, theme, or other supported extension, plus maintainers who package, sort, update, and remove registry entries. It is not positioned as a reusable JavaScript library for application developers.

The repository separates registry coordination from extension source code. The top-level extensions/ directory and .gitmodules file show that extensions are managed as Git submodules. Registry metadata appears in extensions.toml, while scripts in src/ package and modify those entries. This arrangement lets the central repository reference extension repositories as separate source trees instead of folding every extension implementation into one JavaScript package.

The README directs extension authors to Zed's Developing Extensions documentation for implementation details. It also links to issue searches for requested themes and languages. Those pages concern potential future contributions rather than modules users install through package.json. An issue marked needs infrastructure represents a documented boundary: the README says such an extension cannot currently be developed because the required system infrastructure is missing. A request therefore does not by itself establish that Zed can support the proposed extension.

How Zed submodule and TOML registry data fit together

The visible architecture has three layers. Individual extension source trees are checked out below extensions/ as Git submodules. The extensions.toml file records extension registry information. Node-based scripts read and maintain that registry and perform packaging tasks. Supporting files such as package.json, pnpm-lock.yaml, pnpm-workspace.yaml, tsconfig.json, and vite.config.mjs define the tooling environment around those extension checkouts.

The package scripts expose the main registry operations. package-extensions executes src/package-extensions.js, sort-extensions executes src/sort-extensions.js, and remove-extension executes src/remove-extension.js. The build command invokes the TypeScript compiler, while test and test:watch run Vitest in normal and persistent modes. Formatting is handled by Prettier through fmt.

package.json lists libraries for S3 access, TOML parsing, semantic versions, and Git submodule operations. This indicates that the tooling handles more than directory copying, but the README does not describe the complete packaging sequence or every dependency's role. In particular, the existence of @aws-sdk/client-s3 does not establish the destination, authentication method, or release behavior of packaged extensions. Those details require consultation of the repository scripts or Zed's publishing documentation.

Initializing zed-industries/extensions submodules for development

The README does not publish a complete command sequence for preparing this repository. It points extension developers to the Developing Extensions documentation and publishing contributors to the Publishing Guidelines. The repository itself does, however, define concrete submodule recipes that are suitable for a first registry task.

Clone the repository and enter its directory using the URL for the repository, then initialize every extension checkout with the submodule recipe exposed by the justfile.

git submodule update --init --recursive

This is the command underlying the submodules recipe. The recursive option initializes nested submodules as well. After it completes, the extensions/ directory should contain the submodule checkouts registered in the repository. The README does not promise a fixed number of directories, so the immediate check is whether the command finishes without reporting an uninitialized or missing checkout.

The registry toolchain uses pnpm. The README does not state the dependency installation command, so this review does not invent one. Once the documented prerequisites are present, the sorting script defined in package.json is:

pnpm sort-extensions

This command operates on the central registry. It is not a command for installing an extension into the Zed application, and the README does not describe an end-to-end flow from this sorting step to a local Zed installation.

Packaging entries and removing a Zed extension

Packaging is exposed as a distinct registry operation. The justfile defines a package-extensions recipe, and package.json maps that operation to src/package-extensions.js.

pnpm package-extensions

Based on the script name and its registry position, this command packages the registered extensions for the publishing workflow. The README does not state where the resulting artifacts are stored, whether they are uploaded during this command, or how Zed resolves them afterward. Those details should be checked in the Packaging Guidelines rather than inferred from the presence of an S3 dependency.

Removing an extension has two documented consequences. The justfile says remove-extension removes the extension's extensions.toml entry and its submodule. The repository exposes the operation through this template:

pnpm remove-extension {{EXTENSION_ID}}

Because this changes both registry metadata and the submodule relationship, it is not merely a local deletion. A maintainer should identify the intended extension ID and inspect the resulting Git diff. The README does not document a rollback command for this operation, so restoration would require handling the registry entry and submodule state through Git-aware procedures.

Pinning Zed extension revisions with Git submodules

Submodule revisions receive explicit treatment in the justfile. A contributor can initialize all submodules recursively, deinitialize them, reset the entire set, or update one submodule to a specified commit. The reset recipe first removes current submodule initialization and then initializes the registered state again.

git submodule deinit --force .

That command implements the clean-submodules recipe. It is forceful and should be used when the goal matches its deinitialization behavior. The README does not discuss recovery from local modifications inside extension directories, so contributors should inspect nested repository status before invoking it.

A single extension can also be checked out at a specified commit. The justfile expands update-submodule to the following commands:

git submodule update --init --recursive {{SUBMODULE_PATH}}
git -C {{SUBMODULE_PATH}} checkout {{COMMIT_HASH}}

This pins the extension checkout, but the documentation does not state how the new commit hash should be recorded in the parent repository. Contributors must inspect `.gitmodules` and the relevant Git index changes to confirm the intended revision. Local submodule movement by itself does not prove that the central registry entry now references the desired commit.

Publishing review and zed-industries/extensions maintenance limits

Submission is distinct from publication. The README says every submission is reviewed and that not all submissions make the cut. It asks contributors to read Zed's Publishing Guidelines for common problems, selection expectations, and the submission process. Review and possible revision are therefore part of the contribution cost, although the README gives no review time or acceptance rate.

The repository is not archived, and its last push was on 2026-10-16. It has no GitHub releases, so users should not look for a release-based extension version history here. The linked issue queues can change independently of pushes to this repository. Request activity should not be treated as evidence that an extension will be accepted or implemented.

License metadata for the central repository is unknown. Because each extension is a separate submodule, individual source repositories may carry their own licensing terms, but the README does not enumerate them. Inspect the license file in the relevant extension repository before copying or redistributing its code. No legal interpretation of an extension's license should be inferred from its presence in this registry.

Maintenance also includes tool dependencies. package.json pins Node through Volta at 24.21.0 and specifies exact versions for TypeScript, Vitest, Prettier, pnpm tooling dependencies, and other packages. Renovate configuration is present, but the README does not document when dependency upgrades are accepted or whether automated changes are suitable for extension updates.

Choosing zed-industries/extensions or a standalone extension repository

The real alternative is to develop an extension in a standalone repository and use the central repository only when submitting or registering it. This approach separates everyday extension development from central registry maintenance. The extension repository owns its source history, while zed-industries/extensions tracks the submodule and registry entry needed for inclusion in Zed's collection.

A standalone repository is the more direct home for extension implementation work because the central repository's build, test, sort, package, and removal commands are designed around registry maintenance. It is not an adequate replacement when the goal is to enter Zed's published extension collection, because the README specifically identifies this repository and its reviewed submission process.

The choice also depends on the user's role. An end user looking for an available Zed extension should consult Zed's extension distribution rather than clone and build this registry. A contributor can begin implementation elsewhere, but publication still requires compliance with Zed's documentation and acceptance of the review boundary stated in the README.

Editorial conclusion

Adopt this repository if you are contributing an extension for Zed's reviewed publishing process or maintaining registry entries and packaging. Do not treat it as an npm library or a direct extension installer. Before submitting, check compatibility with Zed's Developing Extensions documentation and Publishing Guidelines, confirm the intended submodule, and inspect every extensions.toml change.

Frequently asked questions

Official sources

1. Issues
2. README
3. zed-industries/extensions on GitHub