Lovely forks: a browser extension that points at the fork GitHub buries

The problem: the abandoned repository is the one search engines rank

The README describes the failure mode with unusual precision. Sometimes a GitHub project is abandoned by its original authors and development continues on a fork, but the original repository is seldom updated to tell newcomers, and the author says they have often wasted effort making a pull request or installing old buggy versions of projects when the community had already moved. The reason is discoverability. The old projects usually have higher search engine traffic and many more stars than the forks, which makes the forks even harder to find. The addon tries to remedy that by adding a subscript under the name of the repository on the GitHub page, with a link to the most notable fork, if such a fork exists. The audience is therefore not a researcher looking for a fork deliberately, but a developer browsing GitHub who would otherwise install the dead version. That is a narrow, well-defined job, and the extension is built around doing exactly that.

A star-count heuristic, and a flame for forks that moved ahead

The selection rule is stated in the README, and it is worth knowing precisely, because it is the whole ranking logic. The most notable fork is the fork with the most stars and at least one star, if such a fork exists. So a fork with a single star beats a fork with none, and among forks with stars the most-starred wins, and if the upstream has no star-bearing fork the subscript does not appear at all. The second signal is recency. If the fork is more recent than the upstream, a flame icon is shown next to it, and the README links to the issue where these are called flamey forks, as suggested by another user. The acknowledgements credit a GitHub employee with suggesting the compare API, the commits comparison endpoint, for improving the heuristic that determines whether a fork is more recent than the upstream repository. That is the tell for how the recency check is done, and it is a meaningful design choice, since comparing commit histories is more expensive than reading a timestamp.

The examples show three different reasons to fork

The use cases in the README are worth reading because they show the extension catching forks that search would not. The tipsy plugin had not been updated since 2012 while a community supported fork had merged in all the pull requests, yet at the time of writing the fork had 27 stars against the original's 1,888. The slate project was last updated in 2013 with about 5,000 stars, while the active fork had 185. In other cases the fork is not a continuation but a variant, and the README shows a localisation fork of Semantic-UI, Semantic-UI-pt-br, appearing as notable. A third kind is a fork that adds a feature rather than maintaining a project, with vim-fugitive providing git integration for vim and vim-mercenary providing Mercurial integration. The common thread in all three is that a fork can be the better choice while having a fraction of the attention, which is exactly the situation a star-based heuristic on the upstream page is designed to surface.

One codebase, three browser targets, built by a Makefile

The build system is a Makefile with four useful targets, and the manifest handling is the cleverest part of it. Building for either browser is two make invocations:

make chrome
make firefox

There is a single manifest.template.json, and the Firefox and Chrome targets produce different manifests from it. The Chrome target pipes the template through jq to delete the browser_specific_settings key, while the Firefox target copies the template unchanged and then runs web-ext lint and web-ext build, ignoring a couple of vendored JavaScript files from the lint. The manifest target is the one to use during development, deleting the applications key instead so the same source can be loaded unpacked. In both cases a readybuild step first clears a tmp folder, recreates it, rsyncs the webext source into it while excluding editor backup files, and copies the LICENSE and README along, and the final archives land in the build folder with a name derived from git describe. The manifest is generated rather than checked in, which is why the README warns that editing manifest.json.template is the one case where the fast edit-reload cycle does not apply.

Two ways to test it, and the signing hurdle on Firefox

On Chrome, testing is straightforward. Go to chrome://extensions, click Load Unpacked Extension, and either load the .tmp folder that make chrome produced or run make manifest and load the source root, which gives a simpler edit-reload cycle. On Firefox the project runs into the extension signing requirement, and the README gives a graded set of options. The easiest path is to download the unbranded build or the Developer Edition and load the extension there. Otherwise you have to sign the extension through your account on the addon server, then open about:addons, go to the Extensions tab and use the gear icon to load the packed extension. If the browser still complains that the package is not signed, the README points at about:config and the xpinstall.signatures.required setting, with the caveat that it only takes effect on the Developer Edition and unbranded builds even though it shows up in the release channel about:config pages too. That caveat is the kind of detail that saves an afternoon.

A userscript port, a style guide and no runtime dependencies

The repository layout shows a project that has been modernised but kept its history. There is a webext directory holding the extension source and a userscript directory, the latter added by a contributor who also made the switch from the Firefox Addon SDK to WebExtensions, so the userscript version predates or parallels the WebExtension rewrite. The package.json carries no runtime dependencies at all, with an empty dependencies object, and only development tooling including eslint with the StandardJS configuration, several eslint plugins and web-ext. The README states that StandardJS is the style checker used for the code guide. The licence is MPL-2.0, which is a file-level copyleft licence, and the acknowledgements note that some of the icons come from Freepik and Dave Gandy under CC BY 3.0, so the icon assets and the code are under different terms. The README also points to useful-forks.github.io and its Chrome extension as a related project, which is the closest thing to a curated registry of forks in this space.

A small project, worked on recently, with no tagged releases

The maintenance picture is short. The repository is not archived, the last push was on 2026-10-06, and the version in package.json is 2.6.1, which is also the number that ends up in the archive name since the build derives it from git describe. There are no GitHub releases, so there is no tagged artefact to point at and no changelog of user-facing changes to read. The topic tags list chrome-extension, firefox-addon, firefox-extension, addon, forks, forks-insight, github, github-forks and stars, which is an honest description of a narrow utility. The project also lists contributors by name, including the person credited with improving the look and feel and bringing the extension from what they call the dark age into the space age of JavaScript, and the person who fixed a bug and re-enabled the settings page. For a project of this size, the commit history and the issue tracker are the documentation, and the extension store listing is the distribution channel, since the README links to the Firefox addon, the Chrome Web Store and an Opera listing for the Chrome extension.

Editorial conclusion

Lovely forks fits a developer who has been caught out by an abandoned repository and wants to see, on the GitHub page itself, that the community moved to a fork, without spending a search query on every project they visit. It does not fit a team that needs a curated registry of forks, because the extension only annotates pages you actually visit, and it does not help with the forks that never earned stars. Before installing it, read the heuristic the README describes, since the most notable fork is defined as the one with the most stars and at least one star, and consider the comparison API, which the acknowledgements credit to a GitHub employee for improving the recency check, since the flame icon depends on it.

Frequently asked questions

Official sources

1. Issues
2. License: MPL-2.0
3. musically-ut/lovely-forks on GitHub
4. README