You are seeing Error: running wrong release for app? because the Meteor tool version currently executing (release.current.name) does not match the release declared in the app’s .meteor/release file, and the safety check in the bundler refused to proceed. This check happens very early in the meteor lint flow (same as for build/run) and is intentionally strict unless you explicitly force a different release.
What The Code Checks
Internally release.usingRightReleaseForApp(projectContext) returns false only if ALL are true:
If any of those is false the error will not trigger. So the throw means those three lined up.
Most Common Causes
- The
.meteor/release file in the project lists a different version than the tool you have cached (e.g. file says METEOR@3.3 but the tool running is 3.3.1, or a prerelease/beta vs a final).
- You ran
meteor lint inside a subdirectory that contains (or is inside) another .meteor folder with a different release (multi-app or test harness layout).
- The
.meteor/release file was manually edited (typo, whitespace, capitalization difference, or experimental tag).
- A partial/failed update left
~/.meteor/packages/meteor-tool at one version while the app was updated to another.
- You switched channels (e.g. previously using a dev/beta or custom track) and the cached tool doesn’t match the now-declared stable release.
- Corrupted or stale project metadata (rare)—for example the release file not readable when the tool initialized, causing an empty or fallback value.
- Running from a repo you just cloned where the required release hasn’t been downloaded yet and the initial fetch failed (network/cache error).
(Why during lint? The lint command still constructs a build graph via the bundler, so it hits the same release check.)
Repo / Directory Specific Angle
You mentioned running in tests/ts-test. Double‑check whether:
- That subdirectory (or any parent up to the repo root) contains another
.meteor folder (some test setups do). Meteor walks upward until it finds the first .meteor. If that is not the one you think, you may be pulling a different release file.
- There is a second sample app or harness under
tests/ that pins a different version.
How To Diagnose Quickly
Run these from the tests/ts-test directory (or wherever you ran meteor lint ):
cat .meteor/release
meteor --version
pwd
ls -ld .meteor
If cat .meteor/release shows something different from the first line of meteor --version , that’s the mismatch.
To be 100% sure which .meteor folder is being used, run:
node -e 'let d=process.cwd();const {existsSync}=require("fs");const {join,dirname}=require("path");while(d!=="/"){if(existsSync(join(d,".meteor","release"))){console.log("Meteor root:",d);process.exit(0);}d=dirname(d);}console.log("No .meteor found");'
(That reproduces the upward search Meteor does.)
Fix Options
- Align to the project’s declared version:
meteor update --release METEOR@3.3.1 (if the file wants 3.3.1 but your tool is older)
- Or update the
.meteor/release file to exactly match the tool you intend to use (only if that’s truly what the project should run).
- Force a one‑off run (for debugging, not as a permanent solution):
meteor --release METEOR@3.3.1 lint
(If that succeeds, you know the mismatch was the issue.)
- Clear the possibly corrupt tool version and let Meteor redownload:
(This removes only the 3.3.1 tool directory; adjust version as needed.)
rm -rf ~/.meteor/packages/meteor-tool/3.3.1*
meteor --version
- Meteor will fetch the tool again.
- If multiple nested
.meteor folders exist, run lint from the real app root, or remove/rename the unintended one.
Edge Cases To Consider
- Hidden BOM or trailing spaces in
.meteor/release (open it in a plain text editor).
- Using a forked or custom build of meteor-tool whose name doesn’t match the canonical release string.
- Race condition where you edited
.meteor/release while a long-lived Meteor process was already running (restart the process).
About zodern:types
If your goal was just to generate TypeScript types without a full build, note that the package still hooks into the build graph, so you can’t bypass the release integrity check. Resolving the mismatch is required. (If the package offers a dedicated command in newer versions, use that from the correct app root after fixing the release alignment.)
Recommended Minimal Path Forward
cat .meteor/release → note the version string.meteor --version → confirm mismatch.- If mismatch: run
meteor update --release <that-version> OR edit .meteor/release to the one you actually want and then meteor update.
- Retry:
meteor lint.
If it still fails after versions match, capture both values and share:
.meteor/release contents- Output of
meteor --version
- Exact command + working directory path
Last option
Update to meteor 3.3.2 