Behold, the evolution of Meteor DevTools.
Meteor Devtools Evolved is currently available for Google Chrome and Mozilla Firefox.
Harder, Better, Faster, Stronger 🚀
Are you beginning with Meteor? Do you want to get a sense of "what is going on" or even to optimize your Meteor app? This is the tool for you.
👉 Changelog · Privacy policy · Contributing guide
Inspect, filter, search, and bookmark inbound and outbound DDP messages. Capture
is bounded to the newest 5,000 events, and actionable outbound calls include
stack traces. Applications that use additional DDP.connect connections get a
global connection selector; logs, byte totals, subscriptions, and Minimongo
snapshots remain isolated by server.
The bottom-anchored Settings tab controls whether a newly opened DevTools panel shows messages captured before it opened or starts from current traffic. Show captured history remains the default. Start from now discards cached rows and byte totals for the inspected tab without affecting bookmarks or page data; the panel prompts for an explicit reload before applying a changed startup policy to the active session.
The DDP inspection is ephemeral, but you can save as many DDP messages you want for later search and retrieval, from any host. Be careful though, it is saved on IndexedDB.
Use Edit in DDP Playground on a captured call or Probe in Playground on a subscription, or enter a method/publication name and encoded EJSON parameter array directly. Opening a draft is passive. Select a live connection and press Run to invoke it; older bookmarks and imported cases require an explicit target.
Run keeps the ordinary request and response workflow primary. Observed endpoint browsing and Advanced testing progressively reveal execution contexts, guided expectations, and parameter matrices. History groups reusable cases, immutable snapshots, structured comparison, and reviewed import/export without changing their separate record types.
Application-connection calls and shared publication probes use the current app session. Isolated connections support anonymous execution and explicit reuse of a compatible Accounts session. Stopping observation cannot cancel or undo work already handed to Meteor. Start with the quick start, follow the task recipes, and review the safety guide. The file format documents the stable saved-data contract.
For a short walkthrough using the local Meteor 3 fixture, follow the five-minute replay and access-control demo.
Browse named and unnamed local collections, copy document IDs directly from result rows, and inspect nested documents with persisted expansion depth, expand/collapse-all controls, and highlighted key/value filtering.
The structured query interface runs only against the captured snapshot. It supports dotted selectors, an explicit operator allowlist, sort, projection, and a 500-document result ceiling without evaluating arbitrary JavaScript.
Inspect subscription parameters, readiness, activity, and duration in a responsive table. The Performance panel records explicit Meteor 2 synchronous collection calls and Meteor 3 asynchronous settlement timing while preserving application return values and errors.
Read the full privacy policy for how inspected application data is handled and how local records can be removed.
The extension does not collect or send analytics. Bookmarks remain in your browser's local IndexedDB storage. Playground cases and snapshots use a separate local database. The DDP startup-history preference uses the extension's local settings storage and is not transmitted. Playground runs send explicit requests to the selected application's server. Internal session-reuse credentials stay in the inspected page and bypass ordinary capture and persistence; manually entered payloads can contain secrets and remain visible in ephemeral inspection history. Review redaction before saving or exporting. External links open only when you choose them.
DISCLAIMER: This work is based in part on the Meteor DevTools extension by The Bakery. Which sadly is not maintained anymore. While it is not necessarily a fork, I did use some useful knowledge and architectural decisions, and some things naturally converged into the same most practical solution. Hence the "evolved".
The extension is built with TypeScript, React 19, MobX 7, Blueprint 6, Tailwind CSS 4, Sass, and WXT on Vite 8. WXT generates the Chrome Manifest V3 and Firefox Manifest V2 packages from shared typed entrypoints. Vitest covers deterministic core and build-policy logic. Playwright loads the packaged Chrome extension in bundled Chromium and exercises it against the maintained Meteor 3.5.1 and 2.16 fixtures.
- Node.js 26.5.1
- Yarn 4.12.0, selected through Corepack
- The Meteor CLI used by the pinned fixture release
- Just 1.57 or newer for repository helper recipes
Node 26 does not bundle Corepack. Install and enable the pinned compatible release if it is not already available:
npm install --global [email protected]
corepack enableInstall the root dependencies and both maintained Meteor fixtures, then install Playwright's pinned Chromium revision:
yarn setup
yarn test:e2e:installStart the default Chrome development environment:
yarn devFirefox and explicit Chrome commands are also available:
yarn dev:firefox
yarn dev:chromeThe development command builds and watches the extension, starts
devapp-3.5, and launches a browser instance with the extension installed.
Run the same primary checks enforced by CI:
yarn install --immutable
yarn lint
yarn typecheck
yarn test
yarn build:chrome
yarn validate:chrome
yarn test:e2e:all
yarn build:firefox
yarn validate:firefox
yarn audit
yarn audit:devappyarn audit:all reports the complete dependency graph, including
development-only advisories. See the contributing guide for
the complete local workflow.
yarn test:e2e covers the default devapp-3.5 fixture on port 2100;
yarn test:e2e:meteor2 covers devapp-2.16 on port 2200; and
yarn test:e2e:all runs both sequentially. Each command loads the production
Chrome build in Playwright's bundled Chromium and verifies Manifest V3 startup,
page-world injection, rich deterministic Minimongo snapshots, isolated
secondary-connection data, correlated method success and failure, publication
lifecycles, mutations, bounded traffic, Performance capture, and packaged panel
rendering. Build and validate Chrome first. CI runs the fixtures on separate
matrix runners.
Browser tests run headlessly. The Playground suite exercises the packaged panel
using a test-only inspectedWindow host shim that evaluates commands in the real
fixture tab; this remains distinct from the native DevTools panel smoke below.
After building Chrome, yarn test:ui runs the packaged panel's headless layout,
keyboard, and dialog checks without a Meteor server. Custom UI styling uses
CSS Modules and shared design tokens; see the
UI architecture guidelines.
Chrome does not expose custom DevTools panels through a supported Playwright
page target. Automated tests remain headless. For optional interactive
development, yarn dev:chrome opens a development browser: inspect
http://127.0.0.1:2100, select Meteor, and check the live fixture data.
For optional interactive development on Meteor 2, start yarn devapp:2, run
yarn wxt -b chrome in another terminal, open http://127.0.0.1:2200, and
repeat the panel checks against the random collections and subscriptions.
Run just to list optional helper recipes for development, Meteor maintenance,
and release packaging.
Production extension artifacts are written to .output/chrome-mv3 and
.output/firefox-mv2. Use just build to create store ZIPs in releases/.
devapp-3.5 is the active Meteor 3.5.1 development fixture. devapp-2.16 is
the single maintained Meteor 2 compatibility fixture. Both are blocking Chrome
browser-integration targets. Each fixture uses its Meteor release's embedded
Node/npm toolchain, so run its npm commands through meteor npm.
Both fixtures expose the same versioned validation catalog. Their primary connection publishes 20 projects, 220 tasks, and 510 events with deterministic nested values, dates, arrays, null/missing fields, Unicode, multiline text, and long strings. A real additional connection subscribes to 12 isolated records. Meteor 2 exercises callback calls and synchronous collection operations; Meteor 3 exercises Promise calls and asynchronous collection operations.
The fixture page includes bounded controls for structured and delayed methods,
controlled failures, mutation and publication lifecycles, traffic bursts,
local Performance operations, and reset. Wait for the displayed fixture status
to become ready before triggering scenarios. Automation can use the stable
fixture-only globalThis.__meteorDevtoolsFixture contract; this hook is not an
extension public API.
Both fixtures also provide __meteorDevtoolsPlaygroundFixture for DDP Playground
compatibility tests. Its login('Account A'), login('Account B'), and logout()
helpers use real Meteor Accounts sessions through a passwordless handler that
exists only in the development fixtures. The playground scenarios include
account-scoped and deliberately permissive access, automatic publication data,
readiness timeouts, and delayed methods with server-side invocation counters.
These fixture helpers are not packaged in the extension.
Contributions are welcome. Read CONTRIBUTING.md for setup, development commands, verification requirements, and project guidelines.
The Firefox port of the extension was a contribution made by @nilooy. Thank you! Current releases require Firefox 140 or newer on desktop and Firefox 142 or newer on Android.
Meteor DevTools Evolved is available under the MIT License.