bangumi-data ships a Japanese anime dataset as an npm package

A dataset that arrives through the package manager

bangumi-data is described as raw data for Japanese Anime, and in Chinese as a collection of data on anime series together with their broadcast and news site information. The delivery mechanism is what distinguishes it: it is published on npm as a package, and the README's usage instructions are two lines long.

npm install bangumi-data

const bangumiData = require('bangumi-data');

There is a second route, which matters for anyone who does not want a dependency in the lock file. The README points at a CDN path on unpkg serving the latest data of the v0.3.x line, at a URL ending in dist/data.json, so a page can fetch the dataset directly without an install step.

For the user, the appeal is that a data set becomes an ordinary dependency. It can be pinned in a lock file, upgraded deliberately, and cached by the registry infrastructure, which is a better operational story than a script that scrapes a site at start-up and breaks when the markup changes. The cost is that you take a frozen copy rather than a live feed, and the data is only as current as the last release.

The project also has an ecosystem listing at the bangumi-data/awesome repository, which the README links as the place to see which projects are using the data. That is a reasonable way to judge whether the shape of the data suits your use case, since each consumer shows a different set of fields in use.

The package layout and what the build produces

The packaging metadata is small and clear about the shape of the artefact.

  "name": "bangumi-data",
  "version": "0.3.132",
  "description": "Raw data for Anime",
  "main": "dist/data.json",
  "types": "data.d.ts",

The entry point is dist/data.json and the type definitions are data.d.ts, so an editor gets the shape of each record without anyone having to write a schema by hand. The published files list is restricted to the dist directory and the declaration files, which is why the npm tarball is small: the source data and the scripts that produce it stay in the repository.

The build itself is a Node script, and the scripts section of the package metadata shows the whole workflow:

  "scripts": {
    "build": "node script/build.js",
    "lint": "eslint script/ --quiet",
    "validate": "node script/validate.js",
    "test": "npm run lint && npm run validate",
  },

So a build produces the data file, a separate validation script checks it, and the test script runs lint and validation together. The validator is built on joi, which is a schema validation library, and that is the detail worth pausing on: the data is validated against a declared schema, and the same schema is presumably what the type definitions describe. For a dataset that other people will parse, having a validator in the pipeline is what keeps a broken record from reaching a release.

The repository root reflects the same split. There is a data directory holding the source records, a dist directory for the built output, a script directory with the tooling, and a package-lock.json alongside the configuration files for ESLint, Prettier, the editor and the Node version.

Semantic release drives the version stream

The release history shows a machine-driven cadence. The recent tags are v0.3.231 on 2026-10-12, v0.3.230 on 2026-10-09 and v0.3.229 on 2026-10-04, three patch releases in eight days, and the last push to the repository was on 2026-10-21.

That pattern is explained by the tooling rather than by a person. The devDependencies include semantic-release and its git plugin, and there is a.releaserc file at the top level, which is the conventional configuration point for that tool. The version number in package.json, 0.3.132, is not the version in the published tags, which is the signature of a release process that computes the next version from commit history and rewrites the manifest at release time rather than editing it by hand.

The consequence for a consumer is simple and important. The 0.3.x line is a moving target, with a new patch version every few days, and a data change is exactly the kind of thing a patch release carries. If you depend on the data, pin a version, review the diff between versions before upgrading, and be suspicious of an upgrade that arrives without a changelog entry, because the changelog for a data set is the data itself.

The rest of the tooling is conventional and readable. ESLint runs with the flat config style and the import plugin, Prettier is configured with a plugin for multiline arrays, which is a sensible choice for a project whose output is large arrays of records. There is a Travis configuration and a build badge, and a.nvmrc pinning the Node version, so the build environment is reproducible. The repository also carries a CLAUDE.md, which records conventions for AI-assisted contributions.

CC BY 4.0 is a condition, not a footnote

The licence section of the README is short and specific. The data in the repository is available for use under a CC BY 4.0 licence, attribution is satisfied by mentioning somewhere that the source is bangumi-data, and questions about using the data for a project are directed to the maintainers.

That is a different licence from what most npm packages carry, and the difference has consequences. CC BY 4.0 is a content licence designed for data, not software, and it requires attribution, so a project that ships the data has to carry a credit. It is not a copyleft licence, so it does not oblige you to publish anything of your own, and there is no requirement to open-source the application that consumes the data. The package.json also records the licence as CC-BY-4.0, which is what package managers and licence scanners will read.

There is one wrinkle in the metadata. The repository's own licence classification is recorded as unknown, and the licence file is not among the top-level entries listed for the repository, while the README states the terms in prose. That combination is why the classification is unresolved: a tool looking for a LICENSE file with a recognised identifier finds nothing, while a human reading the README finds a clear statement. If your organisation needs the licence expressed in a machine-readable and file-based form, that is a question to raise with the maintainers, and the README invites exactly that kind of question.

The attribution requirement is easy to honour and easy to forget. A line naming bangumi-data as the source, somewhere in the about page or the readme of the consuming project, is what the licence asks for.

What a data set cannot do for you

The limitation here is not a bug, it is the nature of the artefact, and it is worth stating before anyone builds on it.

bangumi-data is a static dataset delivered as files. There is no query interface, no API and no documented mechanism for pulling a single record, so a consumer that wants one anime title still reads the whole file. For a small application that is a non-issue, and for a web page that wants to list today's schedule it means bundling or fetching a file that contains every series the project tracks.

The freshness question follows from that. The repository moves quickly, with releases every few days, but a consumer only gets new data when it upgrades the package or refetches the CDN file. There is no push, no webhooks and no documented change feed, so a project that needs data to be current within the hour has to build its own refresh mechanism on top.

The data's shape is the other unknown. The records cover series, their broadcast information and their news sites, and the type definitions in data.d.ts are the authoritative description of the fields. The README does not document the schema in prose, so a consumer who wants to filter on a particular attribute should read the declarations and the sample records in the data directory rather than guess from the field names.

The route to a change is documented even if the process is not described in the README. The contributing guide is linked from both the badge and the README, and pull requests are welcomed, so a missing field or a stale record is something the project expects to be raised rather than something you have to work around.

Editorial conclusion

bangumi-data fits a developer building a Japanese media catalogue, a calendar or schedule view, or a recommendation list who wants a structured anime dataset without scraping sites, and who is willing to credit the source. It is the wrong choice for a product that needs live or frequently refreshed data, since the repository publishes versioned copies of the data rather than an API, and it is the wrong choice if CC BY 4.0 attribution is unwelcome in your project. Before using it, read the schema in data.d.ts and the entries in the data directory rather than assuming a shape, pin a version because the 0.3.x line moves often, and keep the attribution line the README asks for.

Frequently asked questions

Official sources

1. bangumi-data/bangumi-data on GitHub
2. Issues
3. README
4. Releases