one-ip's package is named ip and half its deps are pinned to latest

The manifest is named ip and the version is a timestamp

The root manifest is called `ip`, not the project name, is marked private, and declares AGPL-3.0-only. Its version is `26.922.1906`, which is not a semver string in the usual sense but reads as a date followed by a time of day.

That format is produced on purpose rather than by accident. The Makefile has a target for updating the version by Shanghai time, and the file itself is a stub: its default goal prints a list of commands in Chinese and includes four fragments from a `make/` directory, covering configuration, version, application and deployment targets. The English translation of that list is a small development environment with separate targets for the single page app, a combined Vite and worker mode, a build, a test run, a deploy and the version bump.

The toolchain is pinned twice over. The manifest requires pnpm 10.32.1 and Node 24 or newer, and there is a separate node version file at the root. The documentation repeats both numbers in the Cloudflare import instructions, so a fork gets the same constraints without reading the manifest.

The scripts are short and one of them is unusual: the test command does not just run tests, it first produces a dry-run deploy of the worker into a scratch directory and then runs the test files against that output.

Caret ranges and the word latest in the same list

The dependency block mixes three pinning styles, and the distribution is lopsided.

Several packages are pinned to an exact version, including a speed test helper, the current fingerprinting client at 5.2.0, an older fingerprinting library at 2.1.4, and the charting library. Most of the rest use caret ranges. And a long tail of packages is set to the literal string `latest`, which resolves to whatever the registry serves on the day of installation and gives the lockfile nothing to pin against.

The list of `latest` entries includes the form resolvers, the query client, the date library, the animation library, the state library, the icon set, the progress bar, the component primitives package, the form library, the router, the toast library and the schema validator. That is a large fraction of the user-facing stack.

Two other entries are unusual as runtime dependencies. A class name utility is listed with a version range, and the component scaffolding tool is listed as a dependency of the application rather than of the build.

Two different fingerprint libraries appear in the same block, one on a 5.x line and one on a 2.x line under a different package name. Nothing on the visible page says which is used where.

Tests run against the output of a dry-run deploy

The test script is the most informative line in the manifest. It asks the deployment tool for a dry run with an empty environment name and an output directory, and only then runs the test files with a path registration module imported into the test runner.

So the suite exercises a bundled artifact rather than the source tree, and the test discovery is a glob over a flat test directory rather than a runner configuration. That is a reasonable way to catch bundling mistakes, and it also means the tests are as slow as a worker build.

The rest of the tooling is deliberately light. Linting is a single Rust-based linter configured by one file at the root, formatting is a single tool with an import sorting plugin, and the git hook installation is the prepare script. TypeScript is split into three configuration files, one for the application build, one shared and one for tooling, which is the standard arrangement for a Vite project that compiles two different module targets.

A separate script builds the browser diagnostics bundle, so the fingerprint and detection code has its own build step rather than being part of the main bundle.

The health endpoint has no key and four status codes

One endpoint is documented as reachable without any credential, and its contract is spelled out in unusual detail:

curl -fsS 'https://ip.huzhihui.com/api/ip/health?format=text'
curl -fsS 'https://ip.huzhihui.com/api/ip/health'
curl -fsS 'https://ip.huzhihui.com/api/ip/health?ip=1.1.1.1'

A request returns the address, a check timestamp, a score, a status, location, carrier, ASN and a set of flags covering residential, data centre, mobile network, VPN, proxy, Tor, crawler and abuse. The score runs from 0 to 100 with higher being better, and the bands are named: good at 75 and above, moderate from 45 to 74, poor below that.

The failure cases are the interesting part. A missing or invalid score does not become zero, it returns a null score with an unknown status. Missing flags return null and the documentation states explicitly that null is not to be read as false. That is the difference between an absent measurement and a negative one, and it is the kind of thing an API should say out loud.

Errors always come back as JSON, even when the caller asked for plain text, with 400 for an invalid parameter, 429 for rate limiting, 503 when the visitor address cannot be determined and 502 for a data source failure or an address mismatch. Responses are not cached.

One constraint is easy to miss: in local development the address must be passed explicitly, because there is no incoming request for the worker to read an address from.

Two deployment paths and a token that picks one

The project offers two deployment routes and tells you to choose exactly one, because running both publishes twice.

The first is the platform's own build service, connected to the production branch so a push to it builds and deploys. The second is the repository's action pipeline, which builds and tests by default and deploys only when a variable is turned on. That deployment path needs three settings: a boolean variable to enable it and two secrets, one for the target account's deployment credential and one for the account identifier.

Two safety properties are stated. Pull requests from outside run the tests and do not receive the deployment credentials, and pushes created by the platform's own token do not trigger ordinary push workflows, which is why a synchronised fork can land changes without starting a second build.

The fork story has its own workflow, enabled from the fork's own actions page and switched on by a variable set to true. It runs once a day at a fixed hour in UTC, uses the platform's upstream merge interface, needs no personal access token, and stops on conflict while keeping the fork's own commits. The page also warns that a public repository with no activity for sixty days can have its scheduled jobs disabled, which is a real risk for a fork nobody touches.

WebMCP is exposed same-origin and the page ships no trial token

The newest surface is a browser-native tool interface, and the documentation is careful about its own limits.

Where a browser provides the model context object, the page registers structured tools covering address, registration and subdomain lookups, network and service detection, service status and browser diagnostics. Two tools are named: one lists the supported sites, platforms and pages, and one navigates to pages that need a person to approve a permission or complete a human check. Browsers without the interface continue to work normally, so the feature is additive.

The caveats are stated rather than buried. It is experimental, the local test path needs a browser flag and a specific expression to call, and online access needs a browser origin trial programme. The site ships no trial token of its own. Tools are exposed on the current origin only and are not authorised into cross-origin frames.

The privacy paragraph is the one to read before enabling anything. Query results can include third-party data, and the fingerprint, exit address and WebRTC results can be identifying, so the page says the user should decide whether to hand them to an agent at all. That is the same instrumentation the browser detection module collects, exposed through a new surface.

Open source under AGPL next to a closed commercial edition

The same documentation that describes the free deployment describes a paid one.

The business section offers a closed-source commercial version with enterprise licensing and team collaboration, private deployment with data isolation, custom development and API integration, and consulting with deployment and ongoing support, with a contact address for enquiries. The use cases named for the commercial side are network and browser environment detection, service connectivity diagnosis, batch acceptance and continuous monitoring.

That sits next to a project released under AGPL-3.0-only, which is the licence with the strongest copyleft obligation of the common ones for anything offered over a network. The page does not explain how the two editions relate, so a company deploying it internally has a question the documentation leaves open.

The optional configuration is smaller than that. A map token switches the map provider for users inside China, preferring one and falling back to another on failure, and a captcha provider is a second optional layer whose entry point only appears when the keys are present and the requesting domain matches the list. Everything else, including the whole health endpoint, needs nothing.

The interface preview notes that the screenshots have addresses, locations and carriers masked out, so nothing in the images is a live result.

Editorial conclusion

one-ip is worth reading if you are putting an edge worker in front of a network diagnostics front end, because the deployment shape is unusually clean, the optional pieces are genuinely optional, and the health endpoint gives you a documented contract with named status codes rather than a vague failure. Three things to check before you build on it. The dependency list mixes caret ranges with a large block of entries pinned to the string latest, so a fresh install is not the install you tested, and two different fingerprint libraries sit side by side in that list. The documentation is Chinese first with an English file beside it, which matters if your team is not reading Chinese. And the project is AGPL open source with a closed-source commercial edition offered from the same page, so decide early which side of that line you are on.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. Project website
4. README
5. zhihui-hu/one-ip on GitHub