# zotero-night kept bumping its manifest after the last release shipped

> A dark theme for the Zotero interface and PDF reader whose README says development has ceased because Zotero 7 has a native dark mode, yet the manifest reads 0.4.24 while the newest release is 0.1.0-2 from September 2023. Its bugs URL is malformed, its install links point at a different repository, and its auto-update pattern expects tags that were never published.

**tefkah/zotero-night** — Night theme for Zotero UI and PDF

- Repository: https://github.com/tefkah/zotero-night
- Stars: 2,452 · Forks: 39
- Language: SCSS
- License: GPL-3.0
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/tefkah-zotero-night

## The page says development stopped while the branch kept moving

The first thing on the page is a note stating that development of this plugin has ceased, because Zotero has introduced its own native dark mode in Zotero 7, followed by a thank you.

The repository's own metadata does not agree. It is not flagged as archived, and the default branch took its last push on 2026-04-24, which is well after the note was written.

The release history explains the split. The newest releases are two prereleases, `0.1.0-1` from 2023-08-20 and `0.1.0-2` from 2023-09-12, plus one whose name is simply `builds`, published the same day as the second prerelease. Nothing has been released since September 2023.

So the useful reading is that user-visible work stopped in 2023, commits continued afterwards, and no new artifact came out of them. If you are evaluating whether this is a live dependency, the release list is the more reliable signal than the absence of an archive flag.

The note also contains a small grammatical slip, referring to Zotero's `it's own` native dark mode rather than `its own`. That is worth mentioning only because it is the sentence establishing the project's retirement, and it is the first thing a reader sees.

One practical note on versions: the page title names Zotero 6, and the version compatible with the Zotero 7 beta lives on a separate branch called `zotero-7` rather than on the main branch.

## Three package managers, one of them only in the documentation

The build configuration is inconsistent about which tool runs it, and a plugin project makes that visible because the instructions are spread across three files.

The repository carries a pnpm lockfile, so pnpm is what resolves the tree. The build scripts then invoke npm, with the prebuild step running `npm run lint` before anything else. And the README's contribution checklist tells a contributor to run yarn.

Three package managers, one project, no statement about which is canonical. A fresh clone that follows the README installs a different tree than CI uses.

The dependency split is also inverted relative to what you would expect. The runtime dependency list contains the entire build toolchain: esbuild and its sass plugin, eslint and four eslint plugins, typescript, ts-node, prettier-eslint, rimraf, and mkdirp. The development dependency list starts with `css-colors-to-vars`.

For a plugin distributed as a built xpi this costs nothing at runtime, since consumers never run npm install. It does mean the published package metadata advertises a build environment as its dependencies, and it means a production install pulls compilers and linters to build a stylesheet.

Two scripts are also duplicates of each other: `build` runs `tsc --noEmit` before esbuild, and `typecheck` is `tsc --noEmit` on its own. Same work, two entry points.

The version scripts deserve attention too. `postversion` is `git push --follow-tags`, so running `npm version` pushes a commit and tags straight to the remote by itself, with no review step in between.

## The auto-update URL points at tags that were never published

The manifest carries an `xpi` block that drives Zotero's own plugin updater. It names the plugin, and it builds two URLs from templates.

The update link is the interesting one. Its template contains a doubled slash in the repository path, reading `tefkah//zotero-night`, and it substitutes a version into a path prefixed with `v`, producing a release download of `zotero-night-{version}.xpi` under a tag called `v{version}`.

The published releases do not match that shape. They are `0.1.0-1` and `0.1.0-2`, neither carrying a `v` prefix. So the URL the updater is told to fetch is a tag name that was never created.

The version substitution has a second problem behind the first. The manifest version reads `0.4.24`, while the newest release is `0.1.0-2`. Something bumped the manifest through two dozen patch versions, which is what the `postversion` script pushing on every version bump would do, without publishing an artifact for any of it.

The third URL, the release base, points at a download under a tag named `release`, which is not one of the published tags either.

Put together: an updater configured with a malformed repository path, a tag prefix the releases do not use, a version twenty-three increments ahead of anything published, and a base tag that does not exist. The practical consequence is that you should install the xpi by hand and not expect the in-app update path to find anything.

## Two of the three install links point at another repository

The header has a prominent download button, and its target is a fixed asset name on this repository's releases page, ending in `night.xpi`. There is also a second button for the Zotero 7 beta version, which points at a branch rather than a release.

Then the install section says something different. It tells you to download from a releases page under a differently named repository, `ThomasFKJorna/zotero-night`, and repeats that same repository in the install-by-downloading line.

So the page mixes two repository names. The header links to `tefkah/zotero-night` and the instructions link to `ThomasFKJorna/zotero-night`. The author field in the manifest names Thomas F. K. Jorna, which explains the second name as an earlier identity, but a reader has no way to work that out from the page.

There is a third inconsistency in the same area, and it is the one that decides whether the button works. The download button asks for an asset called `night.xpi`. The build script runs a plugin packaging step with the project name, and the update URL template names the artifact `zotero-night-{version}.xpi`. Those are different filenames for what is meant to be the same file.

The instructions also carry a line about Firefox: if you are on Firefox, right-click and save the link as. Zotero is its own application built on Firefox technology, and the xpi is installed into Zotero's plugin manager, so that sentence reads as guidance inherited from an earlier add-on rather than written for this host.

## The contributing guide is still an open to-do item

Under the to-do list there is a checkbox for writing a contributing guide, and it is unchecked.

What stands in its place is the contributing section, and it opens by telling you that getting set up for Zotero plugin development is a bit of a pain in the ass. Then it gives a thirteen-item checklist.

Several items are placeholders rather than instructions. One says to do the Zotero plugin stuff and adds a parenthetical asking the reader to expand on it. Another says to launch Zotero with a debugger flag and `-somethingcaches`, which is a fragment rather than a flag name. The list ends with the observation that you can finally do things.

The versions in the list are also dated. It asks you to download Zotero 60 ESR and to launch Firefox 60.

The rest of the sequence is real and is the standard remote debugging dance: enable remote debugging in the browser developer tools settings, allow remote debugging in Zotero's config editor under its advanced settings, connect to localhost:6100 from the web developer menu, and inspect the main process.

That port number is the one detail worth keeping from the whole section. For a project whose primary contribution path is styling, requiring a live debugger attachment to edit a stylesheet is a large tax, and the unfinished checklist is why it stayed that way.

## A phone photo at the root, and the slow path is admitted

The top-level entries include `IMG-20220419-WA0000.jpg`. That filename is the default pattern an Android phone camera produces, dated 2022-04-19, and it is sitting at the root of the repository rather than in the image folder the project would otherwise use.

Alongside it the root carries the build and packaging machinery: `esbuild.js`, `chrome.manifest`, `start.ini`, `start.py`, a patches directory consumed by a patch-package postinstall step, a typing directory for stubs, and separate content, css, defaults, locale, and xpi directories.

The limitations section is the most useful part of the page, and it is short. Popup menus do not have proper styling on some platforms. And the PDFs are made dark with CSS filter functions, which the page concedes is rather slow.

That second point is worth understanding rather than just noting. The PDF is not recoloured; a filter is applied to what is rendered. That is why it is slow, why it can affect the whole reading surface rather than only the page background, and why the plugin offers a second option matching the background colour. Anyone who reads long documents will feel the cost, and the project says so rather than hiding it.

The two PDF themes are a very dark one and one matched to the background, with a quick toggle to switch between filters. After installing, you activate it through Tools, then Night Preferences, selecting Enable Dark Theme.

## Conclusion

Use zotero-night only if you are on Zotero 6 and want a dark interface plus dark PDFs, because that is the case it was built for and the Zotero 7 path is a separate branch. Everything else should point you at Zotero's own dark mode, which is what ended this project. Three things to know if you do install it. The PDF darkening is done with CSS filter functions, which the project itself lists as slow, so a long PDF will feel it. Popup menus are not properly styled on some platforms. And the download story is confusing enough to trip on: the main button fetches a fixed filename, the install instructions point at a differently named repository, and the build script produces a versioned archive instead. Download the xpi once and keep it, rather than relying on the plugin's own update mechanism, whose URL pattern does not match the tags that were actually published.

## FAQ

### Is zotero-night still being developed?

No. A note at the top of the page says development has ceased because Zotero introduced its own native dark mode in Zotero 7. The repository is not flagged as archived and the default branch took a push on 2026-04-24, but the newest release is from 2023.

### Which version of Zotero does zotero-night support?

The page title names Zotero 6. A separate branch called `zotero-7` holds the version compatible with the Zotero 7 beta, published as the prereleases 0.1.0-1 and 0.1.0-2.

### How do I enable the zotero-night dark theme after installing it?

Open Tools, then Night Preferences, and select Enable Dark Theme. The plugin is installed as an xpi through Zotero's plugin manager.

### How does zotero-night make PDFs dark?

With CSS filter functions rather than by recolouring the document, which its own limitations list describes as rather slow. Two PDF themes are offered, a very dark one and one that matches the background colour, with a quick toggle between filters.

### What limitations does zotero-night document?

Popup menus do not have proper styling on some platforms, and the PDF darkening relies on CSS filter functions, which the page says is slow.

### Where is the zotero-night plugin downloaded from?

The header button fetches a fixed asset named `night.xpi` from this repository's releases, while the install instructions further down link to a differently named repository, `ThomasFKJorna/zotero-night`. The build script produces a versioned archive instead.

## Sources

- [Issues](https://github.com/tefkah/zotero-night/issues)
- [License: GPL-3.0](https://github.com/tefkah/zotero-night/blob/main/LICENSE)
- [README](https://github.com/tefkah/zotero-night/blob/main/README.md)
- [Releases](https://github.com/tefkah/zotero-night/releases)
- [tefkah/zotero-night on GitHub](https://github.com/tefkah/zotero-night)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tefkah-zotero-night
