Discord-Datamining works by diffing the hashed Canary entry bundle on every build

The whole method is a hash comparison on the entry bundle

JavaScript files served to the Discord Canary client have different hashes per build change. That is the hook: the same logical file at two different hashes is two different builds, and diffing the text of the entry file between two builds gives you a changelog nobody had to write.

The method has a scope, and the README states it plainly. Only the entry JS file is compared, not the chunk files, of which there are hundreds. Any feature implemented entirely in a chunk will not show up in the diff at all. That is the single most important thing to understand before you treat a build note as evidence that something changed for users.

The repository layout follows the timeline rather than the code. There are directories for 2016, 2017, 2018, 2019, 2020, 2021, 2022 and 2023, and two files at the root, current.js and current_i18n.js, which are the current versions of the compared entry file and its internationalisation counterpart.

The last push to the repository was on 2026-10-15, so despite the year-named directories stopping at 2023, the tracking itself has not stopped.

Signal and noise: renames look identical to features

The README warns that many build changes are variable renaming, new tabs and newlines, and that these usually change nothing on the user side. In a minified or bundled entry file, a rename produces a diff line that looks exactly like a logic change, and distinguishing the two by eye is unreliable.

There is also an inverse problem: a change that does matter may not appear in the diff. Feature flags, server-side toggles and configuration returned by the API all mean that a code change can ship with nothing visible to a user, and the README's own caveat about chunk files means some features are invisible to the process altogether.

The requested behaviour from readers matches that. If you find a change not yet mentioned, you may comment it on the corresponding commit. The README asks for no replies, no discussion and no off-topic comments, and states that repeated off-topic posting may result in being blocked. Comments are limited to select contributors to prevent abuse, which means the review of contributed notes is a manual bottleneck.

So the practical model is a noisy feed of diffs with human summaries attached by whoever noticed, which is a different thing from a changelog with an author per entry.

Build notes live on commits now, and the archive lives in the wiki

The output format changed at some point and the README documents both eras. Build notes used to be summarized in the wiki. Those older pages remain available and are linked from the README, and the current approach is that every commit with actual noteworthy changes carries a comment tied to it with a short summary of what changed.

That has a concrete consequence for anyone automating this. A commit comment is not a structured field, so extracting a machine-readable changelog from it means parsing prose written by volunteers. The wiki is at least a page you can diff between versions.

If you want change notifications rather than a historical archive, the README offers two routes. Watching the repository and selecting All Activity sends email on every commit, which for a repository that tracks every client build is a high volume. The alternative is an external tool: the Datamine Updates bot, linked from the README as dataminev2, which posts updates to Discord instead.

The choice between the two is volume versus channel. Email on every build tells you about renames too; a bot that filters can be quieter and keeps the notifications where you already read them.

The licensing and affiliation gaps are explicit

The README carries a disclaimer that deserves to be read as a constraint rather than a formality. The contributors state they are not affiliated, associated, authorized or endorsed by Discord Inc. or its subsidiaries, and note that some code found in the repository may be owned by Discord Inc. The stated purpose is educational, and the contributors do not condone sharing the content on social media as your own.

The repository's licence field is unknown, and there is no LICENSE file at the root. Combined with the note that some contained code may be owned by Discord Inc., that means the default position for anything you take from current.js is that you do not have clear permission to redistribute it. Read the disclaimer in full before copying a constant out of it into a product.

The disclaimer also states that the contents may change at the discretion of Discord Inc. or be removed entirely, and that any features discovered are not guaranteed to release. That is the honest framing for the whole project: the notes describe code that shipped to Canary clients, which is a pre-release channel, not a promise about the shipping product.

Where this approach breaks down and what to do instead

The method has one structural weakness that no amount of care fixes: it only sees what is in the entry bundle. If you need reliable information about what a Discord client build contains, the alternatives differ in what they can and cannot tell you.

Reading Discord's user-facing announcements would provide a different perspective, with none of the build-diff noise. Inspecting the network traffic of the client you actually use tells you what your account sees, which is a different question from what any user sees.

The value this repository adds over any of those is history and continuity. Someone has already done the diff and written down what they noticed, across years, and that is not something you reconstruct by hand.

For tooling, the right posture is to treat a build note as a trigger for a check rather than as the check itself. Confirm the behaviour in the client, or in the API your own code calls, before you depend on it.

Editorial conclusion

Follow Discord-Datamining as a signal rather than a source, since a commit can mean a user-facing feature, a rename, or nothing at all, and the repository says so itself. Do not build tooling on current.js as if it were an API. The repository carries no licence and states it is unofficial, so treat anything you take from it accordingly and confirm a feature in the client before acting on a note.

Frequently asked questions

Official sources

1. Discord-Datamining/Discord-Datamining on GitHub
2. Issues
3. README