just-laws: a law library built for reading articles, not searching them

The project goal is stated in one line: make legal text readable

Just Laws is an open source library of the laws of the People's Republic of China, and the site tagline says the original legal text, clear and readable. The description adds the intent: from finding a law to locating a single provision, making every lookup simpler.

That framing is a design decision, and it explains what the project is not. It is not a legal database product with an API and a query language. It is a reading site. The words 法律原文, 清晰可读 are the value proposition, and the feature table is organised around the act of reading rather than around integration.

The scale is modest and honest. The site is built with VuePress 2, the homepage is www.justlaws.cn, the licence is MIT, and the project is maintained by ImCaO with a Chinese description and an English one, A Simple and Convenient Laws Library of China.

The interesting engineering is not the framework choice. VuePress is a static site generator and a law library is mostly text, so the hard part is the pipeline around the content: validating legal versions, validating offence name data, and generating a search index, all of which run before every dev server start and every build.

Nine categories and a separate constitution entry point

The reading experience is described in a feature table, and the structure of the content is the first entry.

The site offers a separate entry point for the constitution and eight law categories, with name filtering and both card and list views. The categories are constitutional relevance, civil and commercial, administrative, economic, social, ecological environment, criminal law, and procedural, which covers litigation and non-litigation procedure. Each is reachable at a category URL on the site, and the constitution is reachable at a separate path with the preamble at the front of it.

The second entry is reading along the chapter structure. The site preserves the part, chapter, section and article hierarchy, long codes are split by part, and a side table of contents helps you locate a position quickly. The example given is the Civil Code, where the left side lists parts and chapters, the body highlights the article number, and a reading tool allows jumping directly to an article.

The third entry is locating and sharing a provision. You can type an article number into the reading tool to jump there, and share and cite a specific article through a fixed article link. That last detail is the one that makes the site useful to reuse, since a stable link to a provision survives the site redesigning its navigation.

So there are three ways in: browse by category, search, or follow the internal structure of a code. Most legal text collections give you the first two.

Version history per law, which is where legal publishing actually gets hard

The feature that distinguishes this from a plain text dump is version awareness. For laws that have been configured with multiple versions, the site shows the current version, historical versions, and versions that have not yet taken effect, together with their effective dates.

That is a hard requirement in this domain and a rare one to see implemented in a hobby project. A statute gets amended, the amended text takes effect on a date, and until that date both the old and the new wording are legally live depending on when you look. A site that shows one text without dates is quietly misleading.

The fourth feature in the table, on distinguishing legal versions, is the one that also drives the build. The version data is not a hand-edited page, it is validated by a script and it can be promoted through a separate command.

The repository layout shows how the content is organised. There is a data/ directory for the source content, a docs/ directory holding the VuePress site, a scripts/ directory with the Node scripts that do the validation and indexing, and a tests/ directory. The LAWS_PROGRESS.md file at the root is the progress ledger, and the README says it holds the complete list, the catalogue baseline date, the collection progress and the items still to be updated.

The README is careful about what that progress file means. The collection rate is calculated on whether a text exists at all, and specific versions and effective dates should be checked against the article page and the official text.

Search covers law names, charge names and article text, and is generated at build time

Search is listed as the first feature, and the README explains what it searches: law names, charge names, and the content of provisions, with a click on a result going straight to the right position.

Charge names are a specific and revealing detail. In Chinese criminal law, an accusation is a named charge that maps to a range of articles, so a search that indexes charge names lets someone who knows the crime, rather than the article number, find the provision. That is a genuine improvement on a plain full-text index over legal text, and it comes from the data rather than from the search engine.

The implementation is a generated index, not a runtime query. There is a script for it, and the scripts are wired into the build:

npm run docs:build

Before the site is built, the versions are validated, the offence data is validated, and the search index is generated. The README says the dev and build commands validate the legal versions and the offence data first, then generate the search index, and that the build output lands in docs/.vuepress/dist/.

There is also a runtime dependency, twikoo at 1.7.13, whose role the README does not document, and VuePress 2 is the only dev dependency, at 2.0.0-beta.48. That last version number is worth pausing on, since a beta release in the site generator is a maintenance consideration for a project you intend to run for years.

The content pipeline has its own commands, and their names tell you the workflow

The npm scripts are unusually explicit for a documentation site, because this is more than a documentation site, it is a content pipeline with validation gates.

There are two validators. laws:versions:validate runs manage-law-versions.js in validate mode, and criminal-offenses:validate runs manage-criminal-offenses.js. There is a corresponding promote command, laws:versions:promote, which runs the same script in promote mode, so the version state machine has an explicit transition rather than an implicit edit.

Two test scripts use the Node built-in test runner directly, node --test, against tests/law-versions.test.js and tests/criminal-offenses.test.js. Using node --test rather than a test framework is a deliberate minimalism, and it works because the tests are checking data invariants rather than exercising an API.

There is also a categories:sort script, node scripts/sort-category-pages.js docs/category, which sorts the category pages, and a search:index script, node scripts/build-law-search-index.js.

Put together, the workflow is: edit content in data/, run the validators, generate the index, build the site. The contribution guide is referenced from the README, and the README says that to add or update a law you prepare the original text following the contributing guide and use the law pipeline to generate a preview for review, which implies the pipeline can produce a preview build for a contributor to check before submitting.

Where the text comes from, and the limit that comes with it

The source is named precisely. The legal text comes from the national laws and regulations database, and the collection scope refers to the catalogue of laws currently in force published by the National People's Congress site.

That provenance is the right way to build such a project, and it comes with a clear limitation. This is a reformatting of official text, not the official text itself, and a reformatting can introduce errors. A mis-transcribed article number, a dropped proviso, or a wrong effective date in a version table would all be invisible to a reader who trusts the site.

The project acknowledges this and asks for help with exactly that. The README invites contributions to correct content, pointing out typos, omissions or version problems, with the law name, the article number and the official source, and to report issues or open pull requests. There is also a message board on the site for feedback.

The MIT licence covers the project as a work, and the terms are the standard permissive ones. It does not, and cannot, grant any authority over the underlying legal texts, which remain the state property they are published as. For anything that matters legally, the README's own instruction stands: check the version and the effective date against the article page and the official text.

On maintenance, the last push was on 2026-10-19, the repository is not archived, and the release list shows release-v1.2.1 on 2026-09-23, release-v1.2.0 on 2026-09-22 and release-v1.1.0 in July 2026. The two September releases a day apart suggest a quick succession of corrections, which is what you would expect from a project whose content is being actively checked.

Editorial conclusion

Adopt just-laws as a reference if you are building something that needs to quote PRC legal text and want a citable structure rather than scraped paragraphs, since it preserves the part, chapter, section and article hierarchy and records effective dates per version. Do not adopt it as your source of truth for a legal opinion, because the project itself says specific versions and effective dates should be checked against the official text, and the collection is still being completed. Before you rely on it, read LAWS_PROGRESS.md for the collection rate and the baseline date, and confirm the article you need exists in the version that applies to your case.

Frequently asked questions

Official sources

1. ImCa0/just-laws on GitHub
2. License: MIT
3. Project website
4. README
5. Releases