web-scrobbler: four stores, a Safari build that needs Xcode, and a lint step for cycles

Four stores, and a bridge for the browser that has none

The installation section is really a routing table, and it is worth reading as one. Chrome users install from the Chrome store listing. Firefox users install from the add-ons site. Safari users install from the Apple store. Edge users install from the Edge add-ons site. Then there is Opera, which is the interesting case: the page sends Opera users to install a third-party addon whose entire purpose is to let them install an extension from the Chrome store. That is not a workaround the project chose; it is the shape of that ecosystem, since there is no first-party store listing for it. The practical consequence is that an Opera user is running something written for a different browser through a translation layer, and the project documents the route rather than pretending the extension is native there. Everything else is symmetric, which is what you would expect from a bundle that compiles down for four browsers from one source.

One build command, three targets, and one of them needs a Mac

The development section gives you a single command and three arguments:

# Build the extension
> npm run build firefox
# or
> npm run build chrome
# or (requires Xcode (xcrun and xcodebuild))
> npm run build safari

Dependencies are installed first, and the built bundle lands in a build directory you can load. The Safari line carries a note in the comment that it requires Xcode and two of its command line tools. Everything else in this repository is platform-neutral, but the Safari target is not, and the checkout says so twice over: there is an Xcode project directory in the root and a separate shell script alongside the release script. So a continuous integration runner on a Linux machine can produce three of the four store artefacts and not the fourth, and the fourth is the one whose review queue you cannot influence. For a contributor that means testing a change across all four stores requires access to a Mac, which is worth knowing before you pick this as a weekend project.

Installing from a checkout is two different procedures with two names

Building from source is one paragraph. If you are on Chrome the page sends you to the browser's own documentation for loading an unpacked extension, which is where the compiled bundle goes: the readme says the output lands in a build directory and that you point the browser at that directory. If you are on Firefox it sends you to a wiki page about installing a temporary add-on instead. Those are the same idea in two ecosystems with two different vocabularies, and the project handles it the right way, by linking each separately instead of pretending they are the same thing. The extension is also installable as a zip file, so if you are reviewing a change rather than building it, the two wiki pages are the difference between a working local install and a confusing afternoon.

The privacy policy is a localised string inside the extension

The privacy link in the readme is not a web page. It resolves to a markdown file inside the source tree, in the English locale directory, which means the text is versioned with the code and shipped as part of the extension's own localised messages. That is a better arrangement than the common one of a policy hosted separately on a site, for two reasons. The disclosure that ships to users and the file a reviewer can read in the source are the same file, so they cannot drift apart between a release and a web page. And it is translated alongside everything else, so the policy a non-English user reads is not a stale copy. The translations work the same way: a dedicated command pulls only the translated strings from the translation platform and then runs a preparation script over them, rather than translators committing files to the repository.

Five linters run in parallel, and one of them looks for dependency cycles

The lint command is not a single tool. It runs five checks at once: the JavaScript linter, a stylesheet linter over the Sass files, a formatter check, a markdown processor, and a tool that reports circular dependencies in the source tree. Four of those are ordinary housekeeping, and a project of this size can justify all of them because the content is code, styles, prose and translations in one repository. The fifth is the interesting one. An architecture built out of pluggable connectors is exactly the shape of project where a cycle between two connectors compiles cleanly and then fails at run time in somebody's browser, and catching that as a lint failure rather than as a bug report is the right place to catch it. Running it as part of the default lint rather than leaving it to continuous integration says the project treats dependency direction as a review concern.

Two compiler configurations, because connectors are not the extension

There are two TypeScript configurations in the root and the type-check command runs both, one for the project and one named for connectors. That split only makes sense if connectors are permitted to be code the project does not control, which is consistent with everything else on the page: developing connectors gets its own wiki page, it is mentioned separately from the extension's own features, and the extension bundles a cross-browser API shim so that third-party code has one surface to target. So there is an explicit seam. The extension is strict about itself, and deliberately more forgiving about what plugs into it. Two smaller details in the same area are worth noting for anyone setting up: the node version is pinned in the conventional file so a contributor's runtime matches the one the builds use, and git hooks are installed from the manifest's prepare step, so a fresh clone has them before your first commit.

Two build tools sit in the runtime dependency list, and every version is exact

The runtime dependency list has five entries and every one is pinned to an exact version with no range at all. Among them are a digest library, which is the shape you need when a service requires a digest of a shared secret in the request, a cross-browser extension API shim, a first-party package for filtering track metadata, and two tools that would normally sit on the other side of the line: the bundler and the stylesheet linter. Putting build tooling in the runtime set costs nothing for an extension that ships as a compiled bundle, but it makes the dependency list read as a description of what the tool is rather than what it needs at run time. The exact pinning is the deliberate trade in the other direction. For something that has to clear four extension stores, each with its own review and its own idea of what changed, a build you can reproduce beats one that quietly picks up a patch release.

Editorial conclusion

Install this if you listen in a browser and want that history recorded somewhere you can query later, and pick the store that matches your browser, with Opera handled through a bridge rather than natively. Two things to weigh before you install it anywhere sensitive. The extension runs in the page you are listening on, so what it can read is bounded by what you grant the store listing, and the project publishes its privacy text as a file inside the extension rather than on a page, which makes it easy to audit in the source. And if you are thinking about contributing, note that the Safari target cannot be built off a Mac, which constrains how you test your change against all four stores. The default branch was last pushed on 2026-10-03 and the newest release is v3.23.1 from 2026-09-18.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. web-scrobbler/web-scrobbler on GitHub