QLDependency: one shell command for Qinglong's missing modules

A dependency installer for a scheduled task panel

Qinglong is a timed task management panel supporting typescript, javaScript, python3 and shell, and it is the runtime that most of the Chinese script automation community runs its cron jobs on. QLDependency is not part of that panel. It is a companion repository that installs the third party language dependencies those scripts assume are present. The repository description puts it plainly: a Qinglong panel all-dependency one-click install script.

The script lives under `Shell/` at the root of the repository. There is no library to import and no configuration file to edit, which is why the entire install path fits in a single `docker exec` invocation. The panel itself is a Docker container named `qinglong` by convention, and the installer runs inside that container rather than on the host, which is why the command shape is `docker exec` piped into `bash` rather than a package manager call.

The other files in the tree explain how the project maintains itself. `.github/` holds the workflow that produces releases, `.releaserc` configures semantic-release style version bumps, `UpToRelease.yml` appears to drive keeping a copy of the newest build, `package.json` and `package-lock.json` pin the release tooling, and `assets/` holds images used by the README. `SECURITY.md` and `LICENSE` sit alongside `README.md` as the usual three governance files.

Why a panel upgrade breaks working cron jobs

The reason this repository exists is a specific behavior change in the panel. Newer Qinglong releases, from 2.10.2 onward, no longer ship every module a script might import. When a scheduled job then fails, the error names the missing package directly, in two common shapes: `Cannot find module 'xxxx'` or `'xxxx' module not found`. The module name in the message is the module you need installed.

This is a class of breakage that is invisible until it bites. A script that has run fine for months suddenly stops, the panel log shows a resolution error rather than a logic error, and the fix is not in the script at all. Installing dependencies one at a time as each error surfaces is the tedious path, and on a panel running dozens of jobs that can mean a long tail of separate installs. The repository's approach is to bundle the whole known dependency set once, at install time, so the tail never gets walked.

The panel documentation is deliberately not reproduced here. The README states that pulling the Qinglong Docker image is not covered, on the grounds that tutorials for that already exist, and points at `docker pull whyour/qinglong:latest` as the assumed starting point. Everything in this repository is about the step after the container is already running.

Three commands, one per network situation

The install instructions differ only in which URL prefix the raw script is fetched through, plus one separate script for newer panel versions. The plain form reaches GitHub directly and is the fastest option from outside mainland China.

docker exec -it qinglong bash -c "$(curl -fsSL https://raw.githubusercontent.com/FlechazoPh/QLDependency/main/Shell/QLOneKeyDependency.sh | bash)"

The domestic variant routes the same file through a proxy prefix, `ghp.ci` or `ghproxy.com`, which is what makes it usable from networks where raw.githubusercontent.com is slow or unreachable. One instruction in the numbered walkthrough uses `ghproxy.com` for that reason.

docker exec -it qinglong bash -c "$(curl -fsSL https://ghproxy.com/https://raw.githubusercontent.com/FlechazoPh/QLDependency/main/Shell/QLOneKeyDependency.sh | bash)"

There is a third entry point for a specific failure. Panel version 2.12 and above can fail to install with the standard script, and the README routes those users to a separate file instead.

docker exec -it qinglong bash -c "$(curl -fsSL https://raw.githubusercontent.com/FlechazoPh/QLDependency/main/Shell/XinQLOneKey.sh | bash)"

Every one of these assumes the container is named `qinglong`. The walkthrough is explicit that if yours has a different name you substitute it, and it tells you to confirm the name first with `docker ps`. That single prerequisite is the most common source of a failed install, since a failed lookup in `docker exec` reports nothing useful about dependencies.

Reading the install as a five step procedure

The documented procedure is short enough to state exactly. Star the repository, SSH into the server or another terminal environment (a NAS or a soft router counts), run `docker ps` to confirm the Qinglong container is up and to note its name, run the one-key command with your container name substituted, and watch the output logs while the progress bar advances. The README warns that the wait depends on machine performance and can be very long on slow hardware, which is the expected behavior of an install that fetches and links a large Node dependency tree. When the final output appears, restart the panel container so it picks up the new modules.

docker restart qinglong

That restart is the step people skip, and it matters: the panel resolves script dependencies in the container process that is already running, so without a restart the newly installed modules may not be visible to the very scripts you installed them for.

For anything that goes wrong, the README does not maintain a troubleshooting section of its own. It points at the closed issues of the repository, filtered as `is:issue is:closed`, which in practice makes the issue history the FAQ. Adding a dependency you need is handled the same way: test it locally, then open a pull request and wait for review before it is merged.

How releases are cut and how current they are

The repository is a Shell project with a JavaScript release toolchain sitting beside it, and the three published releases make the pattern visible. Each release is tagged from a commit hash rather than a version number: `main-78d03c22` published 2026-07-09, `main-476bbc19` published 2025-01-23, and `main-c909cadc` published 2025-01-18. Each carries the same short body, which credits the `actions/create-release` workflow and attaches a `OneKeyQLDependency.tar` archive for download. The default branch is `main`, and the same date as the newest release and the most recent push, 2026-07-09, indicates the tarball is built straight from the branch tip.

The gap between the 2025-01-18 and 2025-01-23 releases, followed by a long quiet stretch and then a 2026-07-09 build, is worth reading honestly. The release notes for all three are a template that says dependencies were added and bugs were fixed, so nothing in the public record tells you which dependencies were added or which bugs. What that means in practice is that the dependency set is a moving target that you learn about only by reading `Shell/`, not by reading release notes.

The project sits at 2,202 stars and 345 forks with 27 open issues, and it is registered under an Apache-2.0 license. That issue count is low for a repository with this many stars, which is consistent with a project whose support burden is carried by issue history and a Telegram group rather than by a maintainer backlog. Contributors are asked to test a new dependency before submitting a pull request, which is the right expectation for a script that will run as root inside a container holding scheduled credentials.

A license file and a disclaimer that point in different directions

Two things about how this repository is presented are worth a reader's attention before running anything. The first is that the repository carries an Apache-2.0 `LICENSE` while the README opens with a long special notice that prohibits republication of its resources by any public account or self-media outlet, disclaims responsibility for any loss caused by a script error, and asks users to delete certain content from their machines within 24 hours of download. An OSI license and a prohibition on republishing are different instruments, and if you are considering vendoring these scripts into your own infrastructure, that gap is the first thing to settle with the author rather than assume.

The second is funding. The README carries a row of promotional links for a personal signing certificate service, an AI API key reseller, a hosting provider, and a streaming account marketplace, plus a GitBook documentation site, a Gitee mirror for domestic access, and an Aifadian page for buying the author a coffee. None of that affects whether the script works. It does tell you the project is maintained by one person who is funding it directly, which is consistent with everything else here: a single shell script, a one-click workflow, and releases cut from the branch tip when there is time.

The repository also records itself as a mirror, stating the original address in a heading and pointing at the Gitee copy for faster access. What remains genuinely useful is narrow and clear: the dependency list inside `Shell/`, the three command variants above, and the version threshold at which you should stop using the standard script.

Editorial conclusion

QLDependency does one job and does it with a single command: it pre-installs the module set that Qinglong 2.10.2 and later stopped bundling, so scheduled scripts stop failing with module-not-found errors. Read `Shell/` before you run it, substitute your real container name instead of the documented `qinglong`, and pick `XinQLOneKey.sh` when your panel reports version 2.12 or newer. Releases land as `OneKeyQLDependency.tar` assets with commit-hash tags, so the July 2026 build is the newest one to compare against.

Frequently asked questions

Official sources

1. FlechazoPh/QLDependency on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases