capacitor-plugins: the official plugin set for Capacitor 8

What the monorepo actually is

The repository contains the official Capacitor plugins maintained by the Capacitor team, and it is organised as one directory per plugin with a matching npm package. The root package.json is marked private and holds no package of its own, so the root exists to orchestrate rather than to publish. The plugin directories follow the package names, and the table in the README links each package to its documentation page on capacitorjs.com and to its source directory. The catalogue runs to eighteen plugins in this repository: action-sheet, app-launcher, app, browser, clipboard, device, dialog, motion, network, preferences, push-notifications, screen-orientation, screen-reader, share, splash-screen, status-bar, text-zoom and toast. The theme is device and platform capability that a browser cannot reach on its own. Motion and screen orientation, push notifications, the splash screen and the status bar are the clearest cases, because each of them maps to a native API on iOS or Android. Clipboard, preferences and share sit at the boundary, where a web implementation is possible but a native one behaves better. The primary language in the repository is Java, with Swift in the topic list, which reflects the Android and iOS implementations side by side.

Version lines: Capacitor 8 now, older majors on older branches

The most important operational detail in the README is a version mapping, and getting it wrong is the most common way to break a Capacitor build. The plugins in the current branch target Capacitor 8. The Capacitor 2 core plugins were bundled with Capacitor itself, so there is nothing to install for that line. For Capacitor 3 the README points to the 1.x version of the plugins, and for Capacitor 4, 5, 6 and 7 it points to the matching major version of the plugin packages. So the plugin major and the Capacitor major are not always the same number, and a project on Capacitor 3 is three majors behind in the plugin versioning while still needing a plugin that matches its core. The published releases show the current line at version 8, with @capacitor/status-bar at 8.0.4, @capacitor/share at 8.0.3 and @capacitor/screen-orientation at 8.0.2, all published on 2026-10-02. The last push to the repository was on 2026-10-07. Because each plugin is versioned independently, a project can end up with a mix of plugin versions, and the README's mapping table is the thing to keep next to your dependency file.

Some official plugins are not in this repository

The second table in the README is the one that catches people out, because it lists plugins that are official but not contained here. The README calls them independent plugins: official Capacitor plugins that live in their own GitHub repositories. Background Runner, Barcode Scanner, Camera, Filesystem, File Transfer and File Viewer appear in that list, and the top level directory listing shows why the split exists. The camera directory and the local-notifications directory are present in the repository, but neither is in the eighteen plugin table, which is consistent with the arrangement described in the independent plugins table, where the Camera entry carries an asterisk that the README does not explain. The practical rule that follows is that this repository is not the full set of official plugins. If you go looking for an API in the table and do not find it, the answer is often that it is an official plugin maintained in a separate repository, and the README points to those with their own repository links. The other place to look is the Capacitor Community, which the README names as the home of more plugins beyond the official set.

The publish matrix and what each channel is for

The root package.json shows a publishing setup built for many packages moving together, and it is worth reading because the channel names tell you which build you are installing. There is a latest channel published with conventional commits, a latest-from-pre channel that graduates a prerelease into latest, and four prerelease channels with distinct identifiers: nightly, which carries a timestamped preid and is published with no changelog, no git tag and no push, alpha, beta and rc, which publish under the next dist-tag. Each of the prerelease publishes uses force-publish so that every package in the monorepo is republished, which is what keeps a set of plugins on the same build. There is also a separate publish:cocoapod script that runs the CocoaPods publication one package at a time with concurrency 1, which is the iOS side of the same release. A release-please manifest and a release-please config in the root show that the version bump and the changelog are generated by tooling from conventional commits, and the CHANGELOG.md at the root is where the result lands. For a consumer, the practical consequence is simple: the latest tag is the stable build, next holds the prereleases, and a nightly build is a timestamped snapshot rather than a version you should pin.

Lerna, Nx, and the maintenance scripts in scripts/

Two build tools appear at the root. lerna.json and the lerna run commands drive the per package build and watch, while nx.json sits alongside it, which is the usual arrangement for a Lerna workspace that also uses Nx for task running. The root scripts show the day to day commands: build runs the build in every package, watch runs the watch mode in parallel with streamed output, lint and fmt run Prettier over the scripts directory, and the publish scripts fan out to Lerna. The scripts directory holds the less obvious tooling, and these are the ones that matter if you work in the repository rather than only consuming it. There is apply-patches.mjs, toggle-local.mjs, update-all.mjs, set-capacitor-version.mjs, and a monorepo helper at scripts/monorepo-tools/android-settings-gradle-fix.mjs that adjusts the Android settings Gradle file for the monorepo layout.

    "build": "lerna run build",
    "watch": "lerna run --parallel --stream watch",
    "lint": "npm run scripts:prettier -- --check",
    "apply-patches": "node ./scripts/apply-patches.mjs",
    "toggle-local": "node ./scripts/toggle-local.mjs",
    "update-all": "node ./scripts/update-all.mjs",

Together they encode the practical rules of the repository: which Capacitor version the plugins are pinned against, how a local build is switched on and off, and how the Android Gradle settings are made to work when many packages sit in one repository. The lint script only checks the scripts directory with Prettier, so the style tooling for the plugin code itself lives elsewhere.

Official plugins against community plugins

The alternative to this catalogue is the community set the README points to, and the difference is one of ownership rather than of capability. An official plugin in this repository is maintained by the Capacitor team in the same repository as the core, on a release train tied to the Capacitor major, with a generated changelog and a fixed channel structure. A community plugin is maintained outside the team, in its own repository and on its own schedule, and the trade is that it may cover a capability the official set does not, or implement it in a way that fits a particular app. The choice that matters in practice is compatibility, because a plugin that is written against a different Capacitor major can compile and still misbehave, and the version mapping in this README is the tool that prevents that. The second alternative is to write the native bridge yourself, which is entirely reasonable for a single app with one unusual requirement, since a plugin is a native implementation behind a JavaScript interface, and the cost is the ongoing maintenance of that bridge across iOS and Android versions. What this repository removes from that calculation is only the part of the work where the bridge already exists and the only question is which version to install.

Editorial conclusion

Adopt the official plugin packages when your Capacitor application needs a device capability that the web platform cannot offer and you want a native implementation that the Capacitor team maintains alongside the core. Do not adopt them as a whole: pick the two or three APIs your app actually uses, because the repository is a catalogue rather than a bundle. Before you install anything, check the version line against the Capacitor major you run, since the README maps Capacitor 3 to the 1.x plugins and Capacitor 4 through 7 to matching major lines while the current branch targets Capacitor 8, and check the licence, which GitHub could not classify for this repository, before shipping it inside a closed source product.

Frequently asked questions

Official sources

1. ionic-team/capacitor-plugins on GitHub
2. Issues
3. README
4. Releases