Add-on Market for Zotero: browse and install plugins

Why Add-on Market for Zotero exists

Add-on Market for Zotero addresses a specific gap in Zotero's plugin workflow. Zotero provides an add-ons installation interface, but this project places a browsable plugin market inside Zotero itself. The README describes the add-on as a place to browse, install, and review plugins without first searching across separate repositories and release pages. Its intended users are people who already use Zotero 7 or a newer supported release and want plugin discovery close to the application.

The scope is narrower than a general software package manager. Add-on Market is presented as a Zotero plugin and targets the Zotero add-on ecosystem rather than desktop applications generally. Its catalog is not embedded by this repository alone: the README identifies `syt2/zotero-addons-scraper` as the data source. Add-on listings that are absent from that source must be submitted to `syt2/zotero-addons-scraper`; the README does not describe a separate submission process inside the market interface.

That separation matters during adoption. A working Zotero installation is necessary, but catalog availability also depends on the selected remote source and the upstream scraping project. The project therefore solves discovery and installation, while data collection remains an external part of the system.

Catalog sources and plugin discovery flow

The documentation identifies six selectable data sources: GitHub, Gitee, jsDelivr, gh-proxy, ghFast, and ghProxyNet. These are source options inside Add-on Market, not six hosting environments specified for the TypeScript client itself. The normal catalog is attributed to `syt2/zotero-addons-scraper`. Users can also connect a custom data source if it follows the project's compatible add-on data format, although the README does not publish that schema.

Based on the repository layout, the add-on is organized under `addon/`, while TypeScript configuration and package metadata sit in files such as `package.json`, `tsconfig.json`, and `zotero-plugin.config.ts`. The client also depends on `fuse.js`, `mitt`, and `zotero-plugin-toolkit`. These package names confirm the project's implementation and toolkit dependencies, but the README does not document the exact search algorithm, request sequence, caching policy, or event flow.

That missing detail limits claims about offline behavior and failure recovery. The catalog comes from external repositories or mirrors, so availability can vary when a selected service is unreachable or incomplete. There is no documented bundled snapshot in the README, and no claim about offline installation should be inferred from the source selector.

Installing the XPI and opening the market in Zotero

The README's user installation route begins with the latest release file named `zotero-addons.xpi`. This is an XPI add-on package for Zotero, not an npm package or a standalone desktop program. The repository identifies Zotero 7 and newer as the target, so users should compare that requirement with their installed Zotero release before proceeding.

Download this file from the latest release:

https://github.com/syt2/zotero-addons/releases/latest/download/zotero-addons.xpi

In Zotero, open `Tools` and then `Add-ons / Plugins`, following the README's installation path for the downloaded XPI. The user should see the add-on appear in Zotero's add-on management interface if the package is accepted by that installation flow.

For the first real use, reopen or return to Zotero after installation. Click the Add-on Market icon in the toolbar, or open `Add-on market` from the `Tools` menu. The market interface is where the user can browse the available catalog and act on plugin entries. The README does not document automatic updates, uninstall behavior, version pinning, or rollback, so those operations should not be assumed from the installation instructions.

Developer setup exposed by the repository

The repository is a TypeScript plugin project with package scripts for local serving, building, linting, testing, releases, and dependency updates. The documented environment template is `.env.example`. It expects paths for the Zotero binary, a development profile, and optionally a separate Zotero data directory. On Windows, the example says the binary path delimiter should be escaped as `\\`. On macOS, the example identifies the binary as `*/Zotero.app/Contents/MacOS/zotero`.

The example file instructs developers to copy it as `.env` and fill in the variables. `ZOTERO_PLUGIN_PROFILE_PATH` refers to a profile created through the Zotero profile manager, while an empty `ZOTERO_PLUGIN_DATA_DIR` allows Zotero to start with its default data. These settings are primarily relevant to contributors running the plugin development environment rather than users installing the XPI.

The package metadata declares `npm run start`, `npm run build`, `npm run lint:check`, and `npm test` as project commands. The exact package installation command is not included in the README, so the repository's own setup sequence should be confirmed before attempting a fresh development checkout. For ordinary users, the XPI route remains the only installation method explicitly documented by the README.

Version 10 changes, maintenance, and upgrade implications

The repository is not archived. Its last push was on 2026-09-08, and the listed releases include V10.0.1 on 2026-09-08 and V10.0.0 on 2026-09-03. The previous listed release, V9.0.2, was published on 2026-04-20. These dates indicate recent project activity, but the repository does not include a changelog explaining the user-visible changes in V10.

The package version is `10.0.1`, matching the newest listed release. A major version transition can carry migration or compatibility costs, especially for a plugin that interacts with Zotero's own add-on system, yet the README does not state whether V10 changes preferences, catalog behavior, installation handling, or minimum Zotero versions. Users considering an upgrade therefore need to inspect the release assets or release notes for that version rather than assuming compatibility from the major number alone.

The project is licensed `AGPL-3.0-or-later`. That identifier matters for redistribution and modification decisions, although this review does not provide legal interpretation. The README does not document an update policy, compatibility matrix across all Zotero releases, or a rollback procedure.

Limits of the market and a manual alternative

The clearest limitation is dependence on a catalog that this repository does not itself produce. GitHub, Gitee, jsDelivr, gh-proxy, ghFast, and ghProxyNet are selectable sources, but the README gives no availability guarantee, synchronization schedule, retry policy, or local-cache behavior. A plugin can therefore be absent from the market even if its project is available elsewhere. The upstream repository is also the stated submission point for new add-ons.

A real alternative is to download a plugin's XPI directly from its own release page and install it through Zotero's `Tools` and `Add-ons / Plugins` interface. This manual route removes the market catalog as a discovery dependency, but it does not provide a unified browser, review view, or source switcher. The difference is straightforward: Add-on Market centralizes discovery and selection, while direct installation leaves discovery and release inspection to the user.

The market is consequently a poor fit for environments that prohibit access to the selected services or require every catalog interaction to use a local source. It is also less suitable when an organization needs documented version controls, because the README does not describe pinning or rollback.

License and security review for a Zotero catalog

The AGPL-3.0-or-later license applies to this project, and the README's data-source section identifies a separate upstream repository for scraped add-on information. Reviewers should keep those two layers separate. The license of Add-on Market does not by itself state the license, provenance, or security posture of every plugin that appears in the catalog.

The README supports browsing and reviewing plugin entries, but it does not document signatures, integrity checks, permission summaries, automatic scanning, update verification, or a marketplace moderation policy. Those omissions do not prove that such controls are absent from the implementation, but they mean the README does not establish them. A cautious adoption decision should therefore include reviewing the selected plugin and its source before installation.

The custom source option adds another review point. The README says compatible add-on data formats are supported, but it does not define the format, authentication model, or trust rules. A custom source should not be treated as equivalent to the named upstream source without confirming how its records and download links are produced.

Editorial conclusion

Zotero users who want a catalogue inside the application should consider Add-on Market for Zotero when its selected source can be reached and its trust requirements are acceptable. Users who need a fully local catalogue, documented rollback controls, or a guarantee about plugin availability should choose another installation route. Before adopting it, verify that the selected source loads in the user's network, inspect the plugin details, and confirm compatibility with the installed Zotero version.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. README
4. Releases
5. syt2/zotero-addons on GitHub