Existing jQuery code is a good reason to keep jQuery
Our jQuery checkout built in 2 seconds, which makes source maintenance approachable if your application already depends on it. The stronger reason to keep jQuery is the code you have: event handlers, plugins, and page updates written against its API. Replacing those working pieces has a cost. I'd assess that cost against the specific problem you want to solve before authorizing a rewrite.
jQuery gives you a common API for selecting page elements, handling events, changing styles, and making requests. The repository includes regular scripts and ECMAScript module variants. That suits a server-rendered application where JavaScript adds behavior to existing HTML. For a new application centered on stateful components, I'd choose the component model deliberately instead of importing jQuery out of habit and inventing that structure later.
What happened when we ran it
Our run installed jQuery commit c2f2786 in 12 seconds and built it in 2 seconds. Installation added 677 packages and occupied 275 MB on disk. The October 14, 2026 sandbox used lab-node:22 in a fresh Debian container with 3 CPUs and 8 GB of RAM, without secrets or elevated privileges. These are source-development measurements. They don't describe the size of the browser script delivered to a visitor.
The overall test command failed with exit code 1 after 143 seconds, while the supplied Mocha summary reported 872 passed and 0 failed out of 872. The tail contains successful Node smoke checks for CommonJS and module builds, followed by JSDOM output reporting 14 passed and 1 skipped. Its final message says all tests passed. The visible success messages and the unsuccessful process exit must both stay in the result.
The 143-second failed command does not establish an assertion failure in the tests named by the tail. That excerpt supplies no explanation for the overall exit status. Nor can the successful Mocha summary erase that status and turn the complete command green. Before making a source contribution, I'd reproduce the full command with its complete output. Diagnosing a missing browser, PHP service, or cleanup failure from this tail would be guessing.
Npm audit reported 0 known vulnerabilities in the measured dependency set. The checkout had 348 files, roughly 56,357 lines of source, and occupied 2.3 MB before installation. Our scan found 9 CI workflow files, a tests directory, and no Dockerfile. The measurement method covers this revision's developer setup and available checks. It does not establish browser performance or make a security promise about applications that use jQuery.
A developer checkout costs more than the browser library
The 275 MB installed environment is relevant if you plan to work on jQuery itself. Ordinary application consumers need the distributed library rather than the repository's development tools. The source build instructions describe output under dist/, with module files under dist-module/. Don't confuse the disk usage of a contributor checkout with the network weight your page will ship.
The README asks for Node, npm, and Git for source work. It separately describes browser unit checks served from the repository root through a PHP-capable local server, without a database. A factory variant accepts an externally supplied window for environments that lack a global one. No hosted API credentials are needed for the library. These documented paths help explain the setup options, but don't diagnose our command's unexplained failure.
Custom builds can remove APIs your plugins expect
The 2-second build we measured makes experimenting with output variants easy, but a custom build changes the API your application receives. The README permits module exclusions and spells out their consequences. Excluding CSS also removes dependent functionality such as effects and dimensions. Replacing the selector module with the native wrapper loses jQuery selector extensions. Those choices require an inventory of what your own code and plugins call.
I'd favor an official distribution unless there's a clear reason to maintain a custom one. The README warns that non-official custom builds are not regularly tested. The 4.0.0 release notes also record callbacks and Deferred being removed from slim, plus the removal of deprecated APIs. A dependency that works with an older full build may need changes for the newer slim path. Smaller output is useful only if the page still behaves correctly.
Old version support has explicit limits
The version-support table gives full support to 4.x, critical-only support to 3.x, and none to 2.x or 1.x. That's a practical reason for a competent maintainer to walk away from a proposed deployment pinned to an unsupported branch. It is also a reason to budget an upgrade on an existing site. Keeping familiar code does not require keeping its obsolete dependency version.
Release 4.0.0 includes concrete migration hazards, including removal of jQuery.trim and the boolean toggleClass signature. Check calls in plugins as well as your own source before upgrading. Our 872 passing Mocha results concern the measured repository revision, not your application's compatibility with a new release. An upgrade decision still needs exercises of the pages that customers use, especially where plugins obscure which APIs they depend on.
October issue activity shows ongoing maintenance
The repository was pushed on October 8, 2026, and GitHub listed 59,916 stars and 95 open issues and PRs. The latest release endpoint returned 4.0.0, published on January 18. October activity includes an open effects PR and updates to dependency-related PRs. That combination shows current work despite the older release date. The combined open count is a queue of issues and pull requests, not a count of confirmed bugs.
I'd keep jQuery in an application where its APIs and plugins already earn their place, while moving to a supported branch. For new HTML behavior, compare Alpine's markup-based approach. For server-driven page updates, compare htmx. For a component application, compare Preact. Make the choice from the next feature you need to maintain. A familiar dollar-sign API is useful when it saves work your team can name.