Plugin development: automatic installation of updates from local source

[Christian Boulanger]

Hi plugin developers,

as far as I can see, there is no way to automatically reinstall a plugin with changing code during development, which means I have to manually uninstall the old and install the changed plugin, which is an impediment for fast iteration. 

I know that I could enable automatic updates but that would mean I would have to constantly increase version numbers and publish the plugin. 

How do you deal with this situation - any tricks? Would it make sense to have a "plugin to install plugins" during development, which could check a file location and reinstall if something has changed?

Thanks for any suggestion. 

[XY Wong]

You may want to read https://zotero-plugin-dev.github.io/zotero-plugin-scaffold/serve.html

(it's a third-party tool)

[Emiliano Heyns]

You don't need to uninstall 

On Thursday, November 13, 2025 at 12:13:48 PM UTC+1 Christian Boulanger wrote:

[Christian Boulanger]

Thanks, I have missed this one! I am curious to see how the tool does the re-installation at runtime...

[XY Wong]

It’s opensource, you can check the code if you are interested in the details 

[XY Wong]

It’s only partly correct (how Zotero loads plugins from source) but mostly wrong with made up details.

I strongly suggest reading the source code, or at least check the documentation I shared above, where it explains through which protocol the reloading happens.

On Thursday, November 13, 2025 at 8:11:50 PM UTC+1 Christian Boulanger wrote:

I know, I was wondering about the technical details. Here's what Gemini Code tells me (since the plugin itself has no technical documentation). I don't kow how accurate this is (it might be partially hallucinated - maybe the stuff with the "Reload" button in Zotero's plugin debug bridge), but it's a start. 

How Zotero Plugin Live-Reloading Works

The core of this development workflow is a clever feature within the Mozilla/Firefox extension framework (which Zotero is built upon). Instead of installing a packed .xpi file, you can tell Zotero to load an extension directly from a folder on your computer. This is achieved by creating a special "pointer file" in Zotero's extensions directory.

Here is a step-by-step breakdown of the process:

1. The Pointer File

During the setup phase of a zotero-plugin-scaffold based project (typically by running npm run postinstall or a dedicated setup script), a special file is created inside your Zotero profile's extensions directory.

• File Name: The name of this file is the ID of your plugin, as defined in your install.rdf file (e.g., my-plu...@domain.com).
• File Content: The file contains a single line of text: the absolute path to the build directory within your plugin's project folder.

For example, if your plugin ID is zoter...@gwdg.de and your project is at /Users/me/dev/zotero-xyz, the pointer file would be:

• Path: ~/Zotero/extensions/zoter...@gwdg.de
• Content: /Users/me/dev/zotero-xyz/build

When Zotero starts, it finds this pointer file and, instead of looking for the plugin within its own directory, it loads the plugin directly from the specified /Users/me/dev/zotero-xyz/build directory.

2. The Watch and Build Process

The second part of the magic is the development server, usually started with npm start. This command does two things:

1. Initial Build: It runs a build script (using tools like esbuild) that takes your source code from the src/ directory, compiles/bundles it, and places the final, ready-to-use plugin files into the build/ directory. This build/ directory has the exact structure Zotero expects for an unpacked extension (install.rdf, chrome.manifest, content/, etc.).
2. File Watching: After the initial build, the script continues to run, "watching" all your source files in src/ for any changes.

3. The Live Update Cycle

Now, with Zotero running and the npm start process watching your files, the live-reload cycle is active:

1. You Edit Code: You make a change to a file, for example, src/main.ts, and save it.
2. Automatic Rebuild: The watch process detects the file change and instantly triggers a new, incremental build. It recompiles only what's necessary and updates the corresponding files in the build/ directory.
3. Zotero Runtime Reload: Here's the key step. Zotero doesn't automatically detect that the files have changed on disk. To trigger a reload, you need to use the "Reload" button in Zotero's plugin debug bridge, which is accessible via Tools -> Developer -> Run JavaScript. A common snippet used is:
   javascript
   Zotero.Plugins.get('your-pl...@domain.com').reload(); Alternatively, many developers use the Zotero-Console plugin, which provides a more advanced console and often a one-click "Reload Scaffolded Plugin" button. When you trigger this reload, Zotero re-reads the plugin files from the build/ directory (which it knows about from the pointer file) and reinstalls the plugin in-memory.

This process allows you to see your code changes reflected in the running Zotero application in seconds, without needing to restart Zotero, rebuild the .xpi file, and manually reinstall it each time. It dramatically speeds up the development and debugging feedback loop.

[Christian Boulanger]

I see - sorry for the ai slop, usually I get good extremely good code explanations from the Claude Code (but was using Gemini). I assume this is where the magic happens: 

https://github.com/zotero-plugin-dev/zotero-plugin-scaffold/blob/main/src/utils/zotero-runner.ts

[XY Wong]

LLMs can produce outdated or even incorrect content on Zotero dev topics.

Re the link: yes. for Zotero 7 or higher, the lib is using Remote Debugging Protocol (RDP), as stated in the doc above. You can play with it using https://github.com/windingwind/zotero-plugin-template (third-party, just to note)

[Christian Boulanger]

Thanks again. This will  make plugin development much more pleasant!  

[Christian Boulanger]

For the record, I removed the wrong LLM answer so that is it not reindexed and re-fed into training data...

[Northword]

For the technical details of how Scaffold installs and reloads plugins, deepwiki's summary is relatively correct:  Zotero Integration | zotero-plugin-dev/zotero-plugin-scaffold | DeepWiki ;  For more detailed technical information, you still need to refer to the RDP protocol documentation.

[Christian Boulanger]

Thanks, that's very useful!  Using RDP is very clever, I didn't even know it existed, but it has already made my plugin dev workflow much more efficient. Thanks for the work. 

[Emiliano Heyns]

It probably also makes the debug bridge superfluous. I'm going to look into that.

[David Hoff-Vanoni]

I thought I'd share a similar approach that I'm using for my plugin. If you're not using zotero-plugin-scaffold but would like to use the same RDP setup without implementing too much yourself, you can use Mozilla's web-ext as a package. I use web-ext in my script for launching my plugin, connected to esbuild for hot reloading.

[XY Wong]

Some more background info that might be helpful, as I see this thread interests  more developers than I expected:

The plugin-scaffold's RDP implementation is based on web-ext, but due to issues like deps warning, redundant code (we don't run on other browsers), and incompatibility, it was decided not to rely on web-ext. See https://github.com/zotero-plugin-dev/zotero-plugin-scaffold/issues/10 for further discussions.

[Christian Boulanger]

Maybe it would be good to have an entry point with information on Zotero plugin development which is community-maintained -  it is a bit hard to find the info in the Zotero developer documentation -  the core devs have other stuff to attend to and it is a fast-moving target mainly driven by the community... The https://github.com/zotero-plugin-dev "organization" could be an entry point, for example. 

[Christian Boulanger]

Thanks everybody, for the advice - it allowed me to complete https://github.com/cboulanger/zotero-rag