# PT-Depiler's release tag carries a build number its manifest does not, and its engine field asks for an odd Node release

> pt-plugins/PT-depiler is a Manifest v3 browser extension for private tracker sites that aggregates search across sites and hands a chosen torrent to a download client. Its manifest declares a fixed build number, requires a specific odd-numbered Node release that the documentation never mentions, warns readers off importing configuration from either of its two predecessor projects, offers to back up session data to six third-party services, and produces a Telegram upload as one of its build outputs.

**pt-plugins/PT-depiler** — PT-depiler is a browser extension (Web Extension) built on the latest Manifest V3 standard, evolved from the original PT-Plugin-Plus, for improving efficiency on PT (private tracker) sites.

- Repository: https://github.com/pt-plugins/PT-depiler
- Stars: 2,664 · Forks: 187
- Language: TypeScript
- License: MIT
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/pt-plugins-pt-depiler

## The release tag carries a number the manifest does not

The manifest declares the version as 0.0.6, and the release list has three tags that all start with that. What follows the patch level is a different number in each case, rising with each release: 1898, then 1927, then 1940, published in the three weeks to the end of September 2026. So the tag is a build counter appended by the pipeline rather than a version a person chose, which is a reasonable way to get a unique artefact per build and a poor thing to depend on: nothing in the manifest explains the suffix, and a reader comparing the two has to notice it themselves. The cadence is worth noting too, three releases in three weeks for a browser extension whose whole purpose is tracking sites that change, which is a project shipping on a schedule rather than on a plan.

## The engine field asks for an odd numbered Node release

The manifest's engine field requires a specific minimum Node version and a minimum package manager version, and the source build instructions in the page name three tools, a version control client, Node and the package manager, without a single version number. The minimum Node version required is a recent minor of an odd numbered release line, which is the branch that receives no long term support designation and that means a contributor has to install a specific interpreter to run the build script. None of that affects an extension user, who installs a built package from a store, and all of it affects a contributor who follows the documentation exactly and hits an engine warning before anything else happens. The same asymmetry applies to the package manager, which is pinned exactly in one field and given a lower bound in another.

## Two predecessor projects, both explicitly warned against

The changelog section is short and its main job is to stop you doing the obvious thing. It says this project is not a simple port of the project it grew out of but a comprehensive rewrite, that migration of historical user data is only supported for sites that have already been adapted, and that you should not import the configuration files of either that project or a second, separately maintained helper directly into this one. That is unusually careful documentation for an extension, and it exists because the failure mode is silent: an imported configuration either half works or produces requests the sites reject, and the user has no way to tell which. The migration path that remains is narrower than the warning implies, so anyone coming from either predecessor should read the status page for their specific sites before expecting their history to come across.

## Backup means sending session data to a third party

One feature line lists six backup services by name: two general file storage providers, one gist host, a cookie focused sync service, two drive providers, and a self hosted one. The purpose is data synchronisation, so a reader should understand what the data is before picking a target. The privacy section says the extension contains no statistics, tracking or telemetry code and that data is by default kept in the local browser, which is a specific and checkable claim about the code rather than a promise. It then points at a separate privacy statement for the scope of collection, how the data is used, where it is stored, who it is shared with, how long it is retained and how to make contact. That document is the one to read, since it is the only place those questions are answered and none of the six answers appear on this page.

## A Telegram channel is one of the build outputs

Two things in the page point at Telegram. One is an invitation badge near the top, the other is a build script whose name says it uploads to a Telegram channel and whose implementation lives in the same directory as the bundler configuration rather than in the source tree. So the release announcement travels through a chat channel rather than only through the release page, and the pipeline has a script that does it. That is a normal arrangement for a project with a user base in one messaging app, and it has the usual consequence: the fastest path to a new build is a message rather than a release note, so anyone not in the channel learns about updates later. The extension stores are the durable channel, and the page lists three of them.

## One store link points at a single language

The installation table has three rows, one per browser store, and the Firefox row is a link to the add-ons listing in one specific language rather than to the listing's default page. That is a small thing that matters for anyone outside that language: the listing they land on is not the one their browser would have chosen, and the page behind it is in that language. Chrome and Edge both link to their default listings. The rest of the installation section is thorough by comparison, with the store route first, then the continuous integration artefacts or the release page, then a source build with three commands and two build targets, one of them for the Firefox build specifically:

```bash
git clone https://github.com/pt-plugins/PT-depiler
cd PT-depiler
pnpm install
# pnpm dev
pnpm build:dist    # or pnpm build:dist-firefox
```

## Pinned dependencies, patched packages and install time hooks

The dependency list is where this project does its real work, and a few entries explain the features. A torrent parsing library plus a promise based queue plus the download client integrations is how a chosen torrent reaches the client without the user copying a magnet link. A state persistence plugin for the store library and an IndexedDB wrapper is how settings survive a browser restart. A job scheduler shim for extensions is how periodic work survives the platform's habit of stopping background pages. Around those sit the charting library for the statistics view, a canvas library, a compression library, a filename validator and a query string parser. The repository also carries a patches directory, a workspace file, a hooks directory and an install script that runs the hook installer, so a fresh clone gets patched dependencies and a commit hook without anyone asking.

## Conclusion

Use this extension if you belong to several private tracker sites and want one search box and one download button instead of five, because that is the whole product and the per-site work is delegated to a status page you are expected to check. Three things to know before you install it. It is not a successor you can point at your old configuration, since both predecessor projects are explicitly named as things not to import from. The backup feature will send whatever it stores to whichever service you choose, and what it stores includes the session data your sites rely on, so pick that service deliberately. And the manifest's requirement for a specific Node release will bite contributors rather than users, since the documentation names the tools without their versions.

## FAQ

### What is PT-Depiler?

A browser extension for private tracker sites, built on the current Manifest v3 standard, that searches several sites at once and can hand a chosen torrent to a download client with one action.

### Which sites does PT-Depiler support?

It says it is compatible with NexusPHP, Unit3D, Gazelle and other kinds of private tracker site, and it points at a status page listing supported sites rather than enumerating them in the readme itself.

### Can I import my settings from PT-Plugin-Plus?

The page says not to. It describes this project as a full rewrite rather than a port, limits migration of historical data to sites that have already been adapted, and names both predecessor projects as things whose configuration must not be imported directly.

### How do I build PT-Depiler from source?

Clone the repository, install dependencies with pnpm, and run the distribution build script, with a separate script for the Firefox target. The manifest requires a specific Node version and package manager version; the readme names the tools without versions.

### Does PT-Depiler send any telemetry?

The page says it contains no statistics, tracking or telemetry code and that your data stays in the local browser by default, and it points at a separate privacy statement for collection scope, storage location, sharing, retention and contact.

### Which download clients does PT-Depiler talk to?

Six are named: qBittorrent, Transmission, Deluge, ruTorrent, Synology's download station and Aria2, and the extension keeps a history of what it has sent to them.

## Sources

- [Issues](https://github.com/pt-plugins/PT-depiler/issues)
- [License: MIT](https://github.com/pt-plugins/PT-depiler/blob/master/LICENSE)
- [pt-plugins/PT-depiler on GitHub](https://github.com/pt-plugins/PT-depiler)
- [README](https://github.com/pt-plugins/PT-depiler/blob/master/README.md)
- [Releases](https://github.com/pt-plugins/PT-depiler/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pt-plugins-pt-depiler