poi: MIT covers the code, and the icons are explicitly not

MIT covers the code, and the icons are named as an exception

The project is MIT licensed and the package metadata agrees, but the licensing section ends with a note in capitals that the software icon and the SVG icons are not licensed by MIT and could not be used in projects not associated with poi. That single line is the part of the license that matters to anyone repackaging the application, and it is written as prose rather than as a separate license file. The tree has one LICENSE file at the root and no second license document for the artwork, so there is no additional text granting other terms for the icons. Everything else about the project, the JavaScript, the TypeScript, the styles and the content, sits under the MIT terms the LICENSE file carries.

Five distribution channels, and two of them belong to the project

Getting poi is a menu rather than a single download. The GitHub releases and an npmmirror binary mirror for mainland China are the project's own channels. The other three are community maintained, and the README marks that table unofficial: an Arch User Repository package, a Homebrew Cask, a Chocolatey package and a Scoop bucket, each with a named maintainer or maintainers. That table is the only place install commands appear on the page, and the two that are written out are `brew update && brew install --cask poi` and `choco install poi`. Nightlies are a fourth route and split by platform, with Windows builds on Appveyor and Linux and macOS builds on a separate nightly site, followed by the warning that artifacts could be periodically emptied.

The source route is three commands and a wiki link

Starting from the repository is the shortest instruction set on the page:

git clone https://github.com/poooi/poi && cd poi
npm install
npm start

The last command is wired to `electron .` in the package scripts, and the two debug variants add flags to the same entry point: start_debug and dev both run electron with a dev flag and an inspector attached. Everything beyond that, including the plugin setup, is delegated to a wiki page rather than described here, and the plugin documentation itself lives on a separate developer site. The plugin list is also a wiki page, which means the set of available plugins is maintained outside the repository and can change without a commit.

Five build scripts differ by one architecture variable and one flag

The packaging matrix is expressed as five npm scripts that all start with the same gulp build and then hand off to electron-builder with a configuration file. build produces the default target. build:x64 and build:arm64 set ARCH to x64 and arm64 through a cross-env prefix. build:all sets ARCH to all, and build:full does the same while also setting FULL_TARGET to true, which is the only extra knob in the set. A sixth script, deploy:nightlies, runs a gulp task of the same name and is what feeds the two nightly destinations. The electron-builder call passes -p never in every case, so no target platform is published from a local build command; publishing is a separate step handled elsewhere in the release process.

Node support is two bands, and version 23 is not one of them

The engines field does not say a minimum version. It says `^22.18.0 || >=24.11.0`, which admits two disjoint ranges and excludes everything in between, 23 included. A machine on 23 satisfies neither side of that expression. A .node-version file at the root pins one specific version for tooling that reads it, which is the practical answer for contributors, and the two bands themselves are at different minor levels, 22.18 on the lower side and 24.11 on the upper, so a contributor on 24.0 would also fail. The package version in the same file is 12.0.1, matching the newest release tag, and the default branch is master, which is the branch the license link points at as well.

stylelint is pointed at tsx files, and three babel configs sit beside a gulpfile

The lint surface is unusually wide. lint:js runs eslint over .js, .ts and .tsx. lint:style runs stylelint over two globs, all css files and all tsx files, so styles carried inside TypeScript components are checked by a CSS linter rather than only by eslint. typecheck runs tsc with noEmit and skipLibCheck. Both lint scripts have fix variants, and lint chains them together. The transpilation side is a different story: three configuration files for the same tool, babel.config.js, babel.config.d.ts and babel-register.config.js, plus a babel-hook.js, and the build itself driven by a gulpfile rather than by a bundler script. The package overrides block rewires babel-plugin-styled-components to the root @babel/core and pins a babel plugin syntax jsx range.

A provisioning profile and two agent instruction files sit at the root

The root listing is a good map of what this project has become. Alongside the usual config files there is poi.provisionprofile, the kind of artifact that carries a macOS signing identity, and it is tracked in the repository rather than ignored, with nothing in the tree stating whether it is a development or a distribution profile. There are also AGENTS.md and CLAUDE.md, and a skills directory, in a project whose own build still runs on gulp and Babel. Views, lib, content, i18n, shims, assets and build each hold one directory, and there are two HTML entry points at the root, index.html and index-plugin.html, which is consistent with plugins loading a page of their own. A .husky directory and a prepare script set to husky wire the commit hooks.

The support channels start in Chinese, the plugin docs are in English

The contact section is ordered by audience, and the ordering is informative. GitHub issues come first, then a Telegram group described as for Chinese speaking users, then a Discord channel under the subreddit's server for users worldwide, then a QQ group and a Sina Weibo account, with or anything else closing the list. Plugin development documentation is the one thing that is explicitly in English, hosted on a developer site rather than in the repository. The feature list itself is short, four items, and only one carries a qualifier: proxy support covers HTTP, Socks5 and PAC, with PAC marked experimental, alongside caching including a custom cache, data synthesis and analysis, notification, and plugin support.

Editorial conclusion

poi is worth using if you play Kantai Collection and want the plugin ecosystem rather than a bare game client, and if you are willing to start from a release binary instead of a source build. Three things to check first. The license is not uniform: the code is MIT, but the icon and the SVG icons are not, so a fork cannot ship the artwork. The supported Node range is two separate bands, 22.18 or newer within 22, or 24.11 and newer, which excludes 23 entirely, so align your tooling before building. And choose your channel deliberately, because only the GitHub releases and the mirror are the project's own, while the AUR, Homebrew, Chocolatey and Scoop entries are maintained by named community members and the nightlies are hosted on two different services with artifacts that get emptied periodically. If you intend to package poi yourself, read the root tree first, including the provisioning profile and the two agent instruction files.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes