HakuNeko is being rebuilt on Electron, NW.js, TypeScript and Vite

A prototype, and the project says so

The README's own summary is short: a prototype of HakuNeko based on Electron/NW.js plus TypeScript plus Vite. That word, prototype, is doing real work in that sentence, and it is the first thing to weigh when you look at this project.

The application itself is a downloader. The package manifest gives the product description as Manga, Anime & Novel Downloader, and the documentation lives at docs.hakuneko.download with a User Manual and a Development Guide, both published online and kept as source in the repository under docs/.

The previous generation of this project was built on NW.js, and this repository is the attempt to rebuild it with a modern toolchain while keeping the two-shell approach. The primary language is TypeScript, the default branch is master, and the licence is the Unlicense, which is the public domain dedication. That last point has a practical consequence: there is no copyleft obligation and no attribution requirement, so the code can be reused in a closed product without negotiation.

The status section of the README is a wall of badges, and each one tells you something about the project. There is a download badge for the stable release and another for the nightly build, a Continuous Deployment workflow badge, a Codacy code quality gate badge, and a Crowdin translation badge, which means the interface is translated by a community through Crowdin rather than by the maintainers alone.

The release history confirms the shape of the project. The listed artefacts are canary builds with timestamp names, 260903T1833 from 2026-09-03, 251105T2353 from 2025-11-05 and 250819T2219 from 2025-08-19. The last push was on 2026-10-20.

Two desktop shells for the same application

The workspace list in package.json is the architectural decision that shapes the whole project:

    "workspaces": [
        "web",
        "app/nw",
        "app/electron",
        "docs"
    ],

There are two desktop application shells, app/nw and app/electron, and one shared web workspace. The intent is that the application logic and the interface live in the web workspace, and the two shells package and run that code, one on NW.js and one on Electron.

That is not a redundancy for its own sake. NW.js embeds Chromium in a window without a separate browser process, which gives a smaller memory footprint and a different startup profile, while Electron has the larger ecosystem and better tooling. Supporting both means the same downloader can be shipped as a lighter NW.js build or as an Electron build, and it means the interface code is not tied to either runtime's API.

The two shells are also why the manifest has type definitions for both runtimes, @types/nw.js at 0.115.0 and @types/chrome at 0.3.5, and why the postinstall script is unusual:

        "postinstall": "npm --workspace=app/electron exec electron -- --no-sandbox --version"

That script does not do work for you, it probes the Electron binary to confirm it runs, with --no-sandbox because that is what it takes to start Electron in many container and CI environments. It is a small thing that tells you the project is developed and tested in environments where a browser sandbox is not available.

The type definitions for chrome as well as nw.js are the other clue: the code touches browser style APIs directly, and the shared interface runs inside a Chromium context either way.

The interface is Svelte, and the connectors talk over websocket-rpc

Two entries in the allowScripts block in package.json reveal the front end and the connector transport.

The first is carbon-components-svelte, which means the interface is built with Svelte using the Carbon Design System components. The second is manga-download/websocket-rpc, which is the mechanism the connectors use to talk to the application. Both are listed in allowScripts alongside esbuild, eslint, fsevents and nw, and the allowScripts map is a modern npm feature that lets a project declare which dependencies are allowed to run install scripts.

The third relevant entry is manga-download/pdfkit. That is the PDF generation library, so the project produces PDFs as well as images, which is the expected output format for the kind of material it handles.

The interesting part is the combination. A Svelte interface running in a Chromium shell, talking to a set of site-specific connectors over an RPC layer, with a document generator for the output, is a design that separates three things that are often tangled together in downloader applications: the presentation, the transport, and the site specific scraping logic. Each connector can be written and updated without touching the interface, and the interface does not need to know anything about the site it is talking to.

It also explains the test strategy, because a connector is a component with a contract that can be exercised independently.

Two test suites aimed at the connectors and the websites

The scripts section of package.json shows how the project tests itself:

        "test:e2e": "npm run build --workspaces && vitest run --config=test/vitest.e2e.js",
        "test:websites": "npm run build --workspaces && vitest run --config=test/vitest.websites.js",

Both suites build every workspace first and then run vitest with a dedicated configuration file, one for end to end tests and one for website tests. There is also a plain test script that fans out across workspaces with npm run test --workspaces, and a check script that does the same for the linting and type checking passes.

The distinction between the two suites is the interesting part. An end to end test exercises the application itself, while a website test runs the connectors against the sites they target. That second suite is the one that tells you whether the downloaders still work, and it is also the one that tells you what breaks when a site changes its markup.

The test tooling supports that. puppeteer-core at 25.14.0 is in the dev dependencies, which is the browser automation layer, and the test suites live in the top level test/ directory with their own vitest configurations. The toolchain around it is modern but deliberate: Vite 8.3.4 for the build, vitest 5.0.5 for the tests, TypeScript 6.0.3, eslint 10.13.0 with typescript-eslint, an @stylistic plugin for formatting, and eslint-plugin-tsdoc for the documentation comments.

There is also a clean install script, npm:clean-install, which runs npm update --package-lock-only followed by npm clean-install --quiet. That is a reproducibility tool, and for a project whose CI produces nightly builds it is a sensible one to have.

Canary builds and the nightly channel

The release naming tells you how this project expects to be consumed, and it is not through a stable package.

The listed releases are all canary artefacts whose names are timestamps, 260903T1833 for 2026-09-03, 251105T2353 for 2025-11-05 and 250819T2219 for 2025-08-19. The README carries two download badges, one for the latest stable release and one for the latest pre-release nightly build, and the badge for the nightly build links to the releases page with the title Download the latest pre-release (nightly build) of HaruNeko.

So the distribution model has two channels, and the stable one is a distinct artefact from the nightlies. Given that the application is described as a prototype, that makes sense: the nightlies are where the rewrite lands first, and the stable release lags behind.

The Continuous Deployment workflow badge in the status section is the mechanism that produces them, and the fact that the build runs in public CI is consistent with the project's transparency posture, which is also visible in the Crowdin badge for community translation and the Codacy badge for the code quality gate.

The practical consequence for someone evaluating it is that the version you install is likely to be a moving target, and that the gap between the current state and the last stable build may be large. That is fine for a prototype and for the community that follows it, and it is a reason to read the development guide before relying on any particular build.

Unlicense, and the question users have to answer themselves

The licence is the Unlicense, and the repository carries an UNLICENSE file at the root. This is a public domain dedication, which means there is no copyleft and no attribution requirement, and the code can be taken into a closed product without negotiation. For a project that exists to be a base for others to extend, that is a coherent choice.

The other side of that choice is that the project cannot lean on copyleft to keep derivative works open, so it has to rely on community interest and contribution, and on the fact that a functioning downloader is worth more than a legally fenced one.

The question the licence does not address is the one users have to answer for themselves. A downloader is a tool, and where it points is decided by the connectors it ships, and those connectors target third party websites. The rights in what those sites serve vary by site and by title, and some of them are licensed while others are not. Nothing in the Unlicense settles that question, and nothing in this repository purports to.

For that reason, the useful framing for a reader is to separate the two things. The engineering is worth studying: a dual shell desktop app, a connector architecture over websocket-rpc, a Svelte interface, and a test suite that runs the connectors against the live sites. The content question is yours, and it is the same question you would have to answer with a browser extension or a command line tool, except that this one is faster and more convenient, which is exactly why the answer matters more.

The development guide in docs/ is the document to read if you want to contribute a connector, and the user manual is the one to read if you want to know which sites the current build supports.

Editorial conclusion

Adopt HakuNeko as a reference if you are building a desktop downloader with connector based site support, since its Electron and NW.js shells, TypeScript workspaces and website test suites are a good model. Do not adopt it as a way to obtain content you are not entitled to, since the downloaders pull from third party sites and the responsibility for the rights in what you fetch sits with the user. Before you build on it, check the connector list in the user manual, read the development guide for the connector interface, and note that the published builds are canary artefacts, so treat the current state as a prototype.

Frequently asked questions

Official sources

1. License: Unlicense
2. manga-download/haruneko on GitHub
3. Project website
4. README
5. Releases