Meteor: a devel branch, three same-second releases, and a package.json at 0.0.1

The three newest releases share one timestamp

The release list does not read like a history of work. All three of the most recent entries are dated 2026-09-08, with timestamps of 12:06:14, 12:06:11, and 12:06:04, so 3.5.2, 3.5.1, and 3.5 were cut within about ten seconds of one another. The tag names explain part of it: they are `release/[email protected]`, `release/[email protected]`, and `release/[email protected]`, a branch-shaped naming scheme rather than a bare version tag. That pairs with the default branch, which is `devel` and not `main`. The consequence for anyone tracking releases is that the list tells you which versions exist and not what is in them. A patch and the two versions before it arriving in the same second means the cut is a batch operation against a moving development branch, so the useful question is not when a version shipped but which commit its tag points at. The repository is not archived, and devel was last pushed on 2026-09-29, so there is always something newer than the newest tag.

The repository's own version is 0.0.1 and it declares no dependencies

The package.json at the root is not the manifest of the product you install. Its name is `meteor`, its version is `0.0.1`, and its own description says this is Meteor's main repository, containing the Meteor tool, core packages, and documentation. There is no `dependencies` block at all, only `devDependencies` carrying build, lint, and type tooling, which fits a container for several sub-projects rather than a publishable package. The code that ships lives in `packages/`, `npm-packages/`, and `tools/`, and the `meteor` and `meteor.bat` launchers sit in the repository root beside it. The consequence is that a version number read out of this repository is the wrong one: 0.0.1 says nothing about the 3.5.2 you would install, and the root manifest will not tell you what the tool depends on either, because the dependency graph belongs to the sub-projects. Anything automating a version check against the source tree has to read the tags instead.

The quick start is three shell lines and the first one is not meteor

The Quick Start section gives the whole entry path in three blocks. On your platform you run one line:

> npx meteor

To create a project:

> meteor create

and to run the project you change into the directory it made and start the tool:

cd my-app
meteor

So the tool arrives through npm rather than through a separate installer, and the name changes between the first line and the rest. `npx meteor` fetches and runs the package, while `meteor create` and `meteor` are the installed command, and a project created by one is run by the other, which is the whole point of the flow. The Installation link in the README goes to a separate page for the non-npx path. The Getting Started section above the quick start offers five tutorials, React, Blaze, Vue, Svelte, and Solid, so the same platform is demonstrated five ways without the README naming one of them as the default.

The lint scripts call oxlint while the dependency list still carries eslint

The npm scripts and the devDependencies describe two different toolchains, and the scripts are the newer one. Formatting and linting are wired to oxfmt and oxlint:

    "fmt": "oxfmt --ignore-path .fmtignore .",
    "fmt:check": "oxfmt --ignore-path .fmtignore --check .",
    "lint": "oxlint --ignore-path .oxlintignore .",

The dependency list still holds eslint at 8.57.1 with eslint-config-prettier, eslint-plugin-prettier, prettier at 3.8.1, eslint-plugin-react, eslint-plugin-react-hooks, eslint-plugin-jsx-a11y, eslint-plugin-import, eslint-plugin-eslint-comments, and the typescript-eslint packages, none of which the fmt and lint scripts invoke. The active tools have their own configuration in `.oxfmtrc.json`, `.oxlintrc.json`, `.fmtignore`, and `.oxlintignore`, and the git hooks come from `lefthook.yml`. The consequence for a contributor is that reading package.json to learn the lint setup sends you to a stack the scripts do not use, and the two sets of rules can disagree about the same file. Type checking is a third matter again, with typescript at 5.9.3, a root tsconfig.json, and type-coverage in the list.

There is no root test command, and the e2e suite installs a browser

The test suites are separate npm projects under `tools/`, and the scripts say so by changing directory first:

    "install:unit": "cd tools/unit-tests && npm install",
    "test:unit": "cd tools/unit-tests && npm test",

The end-to-end script follows the same shape: it cds into `tools/e2e-tests`, runs an install, and then calls `npx playwright install --with-deps chromium`, so that path downloads a browser and its operating system dependencies as part of setup. There is no root-level test script that runs both trees. The consequence is that a contributor cannot type one command at the root and know the project is healthy, and has to decide which of the two trees they are working in. The split is not arbitrary, since a unit run and a browser download have nothing to do with each other in cost, but it does mean the suites are installed and run separately, with an install step before either, and nothing in the root manifest ties them together.

Four documentation trees, five framework tutorials, and agent skills

Documentation lives in the repository as well as on the site. The root holds `dev/`, `docs/`, `guide/`, and a `v3-docs/` directory, alongside a GLOSSARY.md, a History.md, and a LABELS.md. The README links the documentation site and the installation page, and the Getting Started section offers a tutorial per interface library: React, Blaze, Vue, Svelte, and Solid. That is the platform's real strength and also its first ambiguity, since the same capability is demonstrated five ways and the README does not say which library the tool favours. The presence of `v3-docs/` beside the other trees means a reader has to work out which one matches the release they are on, and the repository does not say. The developer resources list adds Galaxy for deployment, Atmosphere for packages, the forums, the Discord, and a page on Meteor Agent Skills for building with AI coding assistants, which pairs with the AGENTS.md and CLAUDE.md files at the root.

package.json says MIT while the root carries a LICENSE and a LICENSES tree

Licensing is stated plainly in one place and left open in another. The root package.json carries the MIT license, and the repository root holds a LICENSE file, a `LICENSES/` directory, and SECURITY.md. The repository's aggregated licence field identifies nothing, so the top level of the metadata points a reader neither at the licence terms nor at the `LICENSES/` tree sitting beside them. For anyone using the tool that distinction is not much of a problem, because the manifest is unambiguous and the MIT terms are short. For anyone redistributing or relicensing it matters more, since the per-file terms in a `LICENSES/` tree are not summarised by the root file, and `.gitmodules` means some content arrives from submodules carrying their own terms. The governance files around it are unusually complete, with GOVERNANCE.md, CODE_OF_CONDUCT.md, ISSUE_TRIAGE.md beside an IssueTriageFlow.png, CONTRIBUTING.md, DEVELOPMENT.md, and a `.coderabbit.yaml`, so the process is written down even where the licence summary is not.

Editorial conclusion

Meteor is a reasonable choice for a team that wants one codebase for web and mobile with the interface library left open, since the tutorials cover React, Blaze, Vue, Svelte, and Solid and the quick start is three commands. Set expectations about the repository rather than about the framework. The default branch is devel, so anything you read there is ahead of a release. The three newest releases share a single timestamp, so tag dates tell you nothing about which change landed in which version. And the root package.json is versioned 0.0.1, so never read a version out of it. Before contributing, read DEVELOPMENT.md and CONTRIBUTING.md, run oxfmt and oxlint rather than the eslint and prettier still sitting in devDependencies, and remember that the unit and end-to-end suites are separate npm projects under tools/ with their own install steps.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes