Meteor Atmosphere packages are a built-in ecosystem used only in Meteor. They have been useful since the beginning because they integrate directly with Meteor’s lifecycle, acting on changes at build time and runtime. Many community packages already exist, adding third-party functionality and helping developers focus on product features. The core is also tied to Atmosphere packages, and while some suggest moving fully to NPM, recent work shows that Atmosphere packages are still being developed.
For a long time, the community has discussed what to do with this Meteor-specific system. Some prefer relying on NPM, and it is true that Atmosphere packages fit some cases better than others. Still, controlling the Meteor lifecycle remains important, as seen with Rspack integration, the current CapacitorJS work, build-time asset serving, runtime module loading for client and server, and Meteor’s integrated testing setup with MongoDB.
This dependency is still a topic. The Meteor core team has not decided to move fully to NPM, as the roadmap focuses on broader priorities like reactive performance, native experience, TypeScript, and testing. A full migration does not seem very realistic, since it would add burden and breaking changes for a community that has already dealt with this for a long time. AI might help, but there is still no clear gain compared to focusing on core improvements, developer experience, and product-oriented features.
There have also been efforts to improve working with Atmosphere packages. Meteor 3.4 added production bundle optimization with devOnly and Npm.devDepends, Meteor 3.3 moved packages to SWC for faster transpilation, and the Atmosphere platform was updated for Meteor 3 to reduce technical debt and improve build and runtime performance.
So far, most changes have focused on performance and optimization. But the issue is also package discovery and learning. Competing with NPM is not realistic, but making Meteor-specific features easier to find, understand, and manage is achievable.
For this reason, in recent months I have been exploring changes to make further improvements on Atmosphere packages, to make them easier to manage, discover, and share.
Two experiments in the CLI
Two branches show what this could look like in practice. Both are still explorations rather than finalized features, but they are functional today and ready for feedback.
Interactive meteor add and meteor remove
The first branch makes meteor add and meteor remove work as interactive commands when run without arguments.
Running meteor add with no package names opens a live search against the Atmosphere catalog. You type to filter, arrow-key through results, toggle any number of packages with <space>, and press <enter> to install the whole selection in one go:
meteor add
If you already know roughly what you are looking for, --search skips straight to filtered results:
meteor add --search blaze
meteor remove works the same way against the packages already installed in the project. The same multi-select applies, so cleaning up several packages at once no longer requires opening .meteor/packages or remembering exact names:
meteor remove
Both forms require an interactive (TTY) terminal. Existing non-interactive usage (meteor add iron:router, meteor remove iron:router, scripted searches via meteor search) keeps working unchanged.
The goal is to make the Atmosphere catalog easier to browse, and the installed set easier to curate, from the place developers already spend most of their time: the terminal.
Support meteor add --from for cloning packages from git
The second branch extends meteor add with a --from flag that clones a package’s source directly into the project’s packages/ directory. It accepts a full Git URL, an owner/repo GitHub shorthand, or a browser-style tree/src URL from GitHub, GitLab, or Bitbucket:
# Full Git URL
meteor add --from https://github.com/nachocodoner/meteor-reactive-publish
# GitHub shorthand
meteor add --from Meteor-Community-Packages/meteor-publish-composite
# tree URL: branch and subdirectory auto-detected
meteor add --from https://github.com/meteor/blaze/tree/master/packages/blaze
--from does register the package in .meteor/packages.
Optional flags cover the cases where the defaults are not enough:
--from-branch <ref>: pin a branch, tag, or commit SHA. Overrides the branch parsed from a tree URL.--from-dir <dir>: extract a single subdirectory of the repository.--to <path>: write to a custom destination, relative to the project root.--force: overwrite an existing destination.
meteor add --from https://github.com/meteor/blaze \
--from-branch master \
--from-dir packages/blaze \
--to packages/my-blaze
The same option landed in Meteor 3.4.1 on meteor create --from, so you can scaffold a new project from a template repository the same way:
meteor create my-app --from https://github.com/meteor/examples/tree/main/parties
Why these matter
Together, these changes target the friction that shows up most often around Atmosphere: finding a package, trying it without leaving the CLI, and getting at its source when you want to read, test, debug, or send a patch back. Interactive search shortens the path from “I think there is a package for this” to actually having it in the project, and --from shortens the path from “I want to see how this works” to having the code sitting in packages/, ready to edit and run inside a real app.
Both branches are still explorations, not final decisions. The command shape, flag names, and defaults may change before any of this lands in a release. I have some pending ideas to improve what is currently delivered, like sort the results by last update. These may be included in future Meteor releases. Feedback on the flow, the ergonomics, and the cases they do not yet cover would help decide what makes it through.