hamuleite: a VitePress index of paywalled social science, finance and textbook sources

What hamuleite actually is, and who it is built for

The README opens with a blunt disclaimer: the repository does not provide any material, and all content is reposted (搬运). That single line sets the boundary for everything else. hamuleite is a link directory. It points at JSTOR, Taylor & Francis, Cambridge University Press, Z-Library, and research from Citron, Morgan and Nomura, but the files stay where they already were. What the project ships is the organisation: a set of topically named folders, a VitePress site that renders them, and a sidebar config.

The stated audience is narrow. The README says it is aimed at overseas Chinese and social science researchers (仅面向海外华人及社科研究者), and it tells users in mainland China to close it and delete anything related within 24 hours. That is a warning about legal and platform risk, not a technical note. Anyone evaluating hamuleite for a university library, a corporate research team or a public service should treat that warning as the project's own description of its intended scope, and decide whether they fall inside it.

The folder list shows the editorial line. There is 拒绝知网 (refusing CNKI), which the README describes as prioritising top international journals over the domestic database. There is 中国家庭与个人生活调查研究, gathering large Chinese panel survey data entrances. There is 书库整合 for textbooks from Taiwan, Hong Kong and Singapore. The topics field lists academic, economics, humanities, research, skills and sociology. Nothing here is a dataset; everything is an entry point.

How the VitePress layer turns folders into a browsable index

The mechanism is ordinary static-site generation. package.json declares the project private and sets "type": "module", with three scripts: docs:dev, docs:build and docs:preview, all delegating to vitepress. The only two dependencies are vitepress at ^1.6.4 and vitepress-sidebar at ^1.33.0, both devDependencies. There is no runtime server, no database and no crawler.

The content flow is file-driven. Markdown and index files live in the top-level folders, a .vitepress/ directory holds the site config, and public/ holds static assets. vitepress-sidebar is what generates the navigation tree, which matters because the folder names are the taxonomy: a reader browsing the sidebar is browsing the directory structure. Adding a topic means adding a folder and its markdown, not editing a schema.

That design has a consequence worth naming. Because the site is generated from the repository tree, the quality of the index is exactly the quality of the links inside those folders. There is no validation step in package.json that checks whether a URL still resolves. Link rot is therefore invisible at build time: docs:build will succeed even if half the external links are dead. The repository also carries a .github/ directory, so some automation exists, but the README does not describe a link-checking job, and no release has been published.

The README also notes that the contributors chart was dropped because the git history was too large for contrib.rocks to generate it. That is a small but real signal about how the repository grew: by accumulation rather than by pruning.

Running hamuleite locally: install and first build

The README gives no installation instructions, so the only usable source is package.json. It defines the project as a Node package with VitePress as a dev dependency, which means the standard route is a Node toolchain and npm. Clone the repository, then install:

npm install

This reads package-lock.json, which is present at the top level, so the dependency tree is pinned. After it finishes you should have node_modules/ containing vitepress and vitepress-sidebar. Then start the local preview server:

npm run docs:dev

VitePress serves the site on its default development port and watches the markdown for changes. The README does not state the port, so read the URL printed in the terminal rather than assuming one. To produce the static output instead:

npm run docs:build

That writes the generated site to the VitePress output directory, and `npm run docs:preview` serves that build locally so you can check it before deploying. A first real use is simply browsing: open the sidebar, pick 全球顶级期刊与金融财团研究文献入口, and follow a publisher link out. What you should see is a navigation page, not a PDF. If you expected a download, this is the moment the project's own disclaimer becomes concrete.

The structural limitation: an index with no enforcement

The most important thing to understand about hamuleite is that its value decays. Every folder is a list of external URLs, and external URLs for paywalled publishers, shadow libraries and file-hosting mirrors change or disappear without notice. The repository has no mechanism described in package.json or the README for detecting that. A build passing tells you the markdown is well formed, nothing more.

The second limitation is legal and operational. The README itself says the library provides no material and that everything is reposted. The project has no licence file at the top level, so the terms under which the index text can be reused are unstated; the linked content sits under the terms of whoever hosts it, which for Z-Library and similar sources is contested in several jurisdictions. The README's 24-hour deletion instruction for mainland China users reads as the author's own acknowledgement of that exposure.

The third limitation is fit. If you need a citable, stable, rights-cleared collection, hamuleite is the wrong tool: it is a personal navigation aid that grew into a public one, and the README's own history note says the folder naming dates back to 2018, when the author was a student. It is honest about being a map. It is not a library.

How hamuleite differs from Zotero, Awesome lists and library discovery

The closest functional comparison is a curated awesome-list on GitHub. Both are markdown link collections. The difference is presentation and structure: hamuleite compiles to a VitePress site with an auto-generated sidebar, so the taxonomy is browsable and searchable in a browser without reading raw markdown. An awesome-list stays a single long file. If your need is a readable site you can host yourself, hamuleite's build step is the reason to pick it.

The comparison with Zotero is sharper and less favourable. Zotero stores metadata for individual items, supports citation export, and lets you attach or annotate the PDF. hamuleite stores neither items nor metadata; it stores destinations. You cannot generate a bibliography from it, and you cannot tell from the repository whether a given paper is still reachable. A researcher who needs citations should use a reference manager and treat hamuleite as a discovery surface that feeds it.

Against a university library's discovery layer, the difference is authority and access. A library catalogue knows what the institution has licensed and can resolve to full text for its members. hamuleite has no authentication, no holdings and no resolver. It is faster to browse and broader in what it points at, including material no library would license, and correspondingly it offers no guarantee that anything behind a link is legitimate or permanent.

Maintenance, upgrade cost and licensing

The repository is not archived, and the last push was on 2026-09-20, one day before this writing, so the project is being touched. That says nothing about link quality, only that commits are landing. There are no releases, so there is no versioned artefact to pin; you track master. The default branch is master, not main.

Upgrade cost is low by construction. Two dev dependencies, both VitePress-related, and a lockfile. The realistic maintenance work is not in the toolchain but in the links: content upkeep is manual, and nothing in the repository automates it. If you fork hamuleite for your own use, budget for periodically re-checking the URLs in whichever folders you depend on, because the project will not do it for you.

On licensing, the honest answer is that the repository does not state one. There is no LICENSE file among the top-level entries. That means the reuse terms for the index text are unclear, and it means the linked material is governed entirely by its own hosts: publisher terms for JSTOR, Taylor & Francis and Cambridge University Press, and whatever applies to the shadow-library sources the README names. This is a description of what the repository contains, not legal advice; if you plan to redistribute the index or the material behind it, that question belongs with someone qualified to answer it.

Editorial conclusion

Adopt hamuleite if you want a structured, browsable list of where social science, finance and textbook material lives, and you are willing to follow the links yourself. Do not adopt it if you expect a working downloader, a mirrored archive, or a maintained API; the repository states plainly that it provides no material and that everything is reposted from elsewhere, and there is no licence file at the top level. Before relying on it, check whether the specific folder you need (拒绝知网, 全球顶级期刊与金融财团研究文献入口, 书库整合) still points at live sites, and read the README warning about who the project says it is for.

Frequently asked questions

Official sources

1. hoochanlon/hamuleite on GitHub
2. Issues
3. README