vimcolorschemes: a daily-refreshed index of vim and neovim colour schemes

The problem is that a theme screenshot lies

The site describes itself in one line: find your next vim colorscheme. The About section expands on what that means in practice.

vimcolorschemes is a website for browsing vim and neovim colorschemes from repositories across GitHub. The app tracks thousands of repositories, updates them daily, and renders generated previews for each colorscheme. It includes repository metadata and filters for sorting and browsing the collection.

The design decision is the preview, and it is worth understanding why it matters. A colour scheme repository usually contains a screenshot, and that screenshot is a picture of one editor, with one terminal theme, with the author's own prompt and status line, taken at some point in the past with a particular background. It tells you very little about how the scheme will look in your setup, and nothing about the syntax colours that matter for the language you actually write.

A generated preview removes all of that. The scheme file is applied to a known piece of sample code, in a known editor, with a known terminal background, and the result is rendered. Every theme in the collection is therefore directly comparable, and the comparison is about the theme rather than about the screenshot.

The second part of the design is the daily update. A theme repository is a moving target, and a static gallery of screenshots goes stale. Tracking the repositories and refreshing daily means the gallery reflects what the themes look like now.

The homepage is vimcolorschemes.com and the documentation lives at docs.vimcolorschemes.com. The licence is MIT, the primary language is TypeScript, and the topic list names colorscheme, neovim, nvim and vim.

A Next.js app on Cloudflare Workers with a Go crawler

The stack badges in the README are a map of the architecture, and they are unusual enough to be worth reading closely.

The front end is Next.js. The data layer is SQLite and Turso. The tests are Vitest with the Testing Library. The crawler is Go. The hosting is Amazon Web Services and Cloudflare Workers.

So there are two languages doing two different jobs, and the split is not accidental. A Next.js application on Cloudflare Workers is a good fit for a read-heavy browsing site with server rendering and edge caching, and Go is a good fit for a crawler that clones and processes thousands of repositories on a schedule.

The Cloudflare deployment goes through OpenNext, going by the opennextjs-cloudflare scripts in package.json. The package.json scripts show the deployment flow in detail.

pnpm exec opennextjs-cloudflare build

And the deploy script wraps that build in a helper, node scripts/with-remote-db.mjs, before invoking wrangler deploy. The same helper is used for the preview script, which runs the build and then opennextjs-cloudflare preview.

There is a separate populate step, pnpm exec opennextjs-cloudflare populateCache remote --rclone, which pushes the cache out to remote storage, and a versions upload command using wrangler versions upload. And there is a typegen script, wrangler types, which generates the CloudflareEnv interface so the Worker bindings are typed in the application code.

The.env file at the repository root holds the environment, and the scripts/ directory holds the search manifest generator, the remote database helper and the build wrappers.

A generated search manifest, built before every dev and build

One script in the package.json deserves attention, because it explains a design choice that would otherwise look odd.

The predev and prebuild hooks both run pnpm search.generate, which is node scripts/generate-search-manifest.mjs.

So the search index is a generated artefact, produced before the dev server starts and before the build runs. That is a deliberate decision: the site does not query a search service at request time, it ships a manifest that the client can use.

The likely reason is cost and latency. A site that indexes thousands of themes with text search over repository names, descriptions and metadata has two options. It can call a hosted search API on every keystroke, which is a per-request dependency and a recurring bill, or it can generate the index as part of the build and serve it statically.

There is a database/ directory with a seed script, ./database/seed, and the Turso and SQLite badges suggest the relational data, the themes and their metadata, lives in a database that is queried for the structured parts, while the free-text search runs off the generated manifest.

The check script ties the whole quality story together in one command.

pnpm run --parallel '/^(lint.check|format.check|tc|test)$/'

That runs the linter in check mode, the Prettier check, the TypeScript type check and the test suite in parallel, and a check.fix variant runs the linter and formatter before the type check and tests.

pnpm is enforced, and the toolchain is pinned

The package.json has a preinstall hook, and it is a one-liner.

npx only-allow pnpm

That fails the install if you tried to use npm or yarn. The reason is the pnpm-workspace.yaml and pnpm-lock.yaml at the root, and the fact that the Cloudflare deployment scripts call pnpm exec directly. With a lockfile generated by one package manager and installs performed by another, the dependency tree is not reproducible, and a site whose entire content is generated from a crawl is the last place to want that.

The engines field pins a Node version, and there is a .nvmrc file for the same reason, so a contributor's node version matches what the build expects.

The rest of the tooling is the modern set. ESLint with a flat config at eslint.config.mts, Prettier with a .prettierrc, TypeScript with a tsconfig.json, Vitest with a vitest.config.js, and a Turso client for the database. The primary language is TypeScript and the package version is 6.2.0.

The release history shows a v6.2.0 tagged on 2026-10-02, a v6.1.0 from 2026-07-22 and a v6.0.1 from 2026-05-15, and the last push was on 2026-10-08. The project moves in step with its own dependencies, and the major version tracks the Next.js and platform version bumps, which is what a site like this has to do to stay on a supported runtime.

A community project with a documented contribution path

The Get involved section is short and points at two places.

vimcolorschemes is a collaborative project. Code, documentation, bug reports, and feature ideas are welcome. Developers are pointed at the development guide to start writing code and contribute, and bugs and feature requests go to the GitHub issues tracker, with a note to follow the issue template before posting.

The contributor list in the README is generated by the all-contributors tool, and it shows a pattern in the roles. Robin Gagnon appears with code, design, documentation, maintenance and infrastructure, which is a short list for one person but a clear statement of who holds what. The other names appear mostly with a code emoji and some with the ideas, planning and feedback emoji.

So the governance is informal and the work is distributed. That fits the project, because the interesting input is not code, it is the schemes themselves. The site exists to gather them, and the crawler is the part that benefits most from a steady stream of small fixes, since a scheme repository that changes structure or a preview renderer that trips on a particular scheme is a routine occurrence rather than an exceptional one.

The credits section says the credit goes to the creators of vim and neovim colorschemes across GitHub, which is the right priority for a project whose content is other people's work.

What the collection does not cover

The model has boundaries, and they follow from the design.

The app tracks repositories across GitHub, which means a colour scheme that is not published in a GitHub repository, or is published somewhere the crawler does not look, is not in the collection. A scheme distributed only as a download from a personal site, or a theme inside a larger plugin repository that does not follow the expected layout, is out of scope by construction.

The daily update has a related consequence. The index reflects what the crawler found, and a repository that is renamed, deleted or made private disappears from the collection without a trace being visible to a user who had it bookmarked.

The preview rendering has its own limits. A generated preview shows the scheme applied to fixed sample content in a known editor. It does not show how the scheme handles your particular plugins, your filetype, a terminal with a coloured background, or a light mode setup.

And the filters are described only as filters for sorting and browsing, with no indication in the README of which facets are available, so the practical breadth of the collection cannot be judged from the repository alone.

None of this is a criticism of the project, which is a well-built gallery for what it sets out to do. It is a description of where the boundary is, so that a reader knows that a theme preview here is a starting point rather than a substitute for installing the scheme and looking at it in their own editor.

Editorial conclusion

vimcolorschemes suits a Vim or Neovim user who wants to pick a theme by looking at it rather than by guessing from a repository screenshot, since the previews are generated from the actual scheme files and the index refreshes every day. It is the wrong tool if you want to host your own copy, because the collection depends on the daily crawl and the hosted preview service, and it is the wrong choice if you need themes that are not on GitHub, since the whole model is repository tracking. Before you rely on it, read the development guide at docs.vimcolorschemes.com if you plan to contribute a missing repository.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. vimcolorschemes/vimcolorschemes on GitHub