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.
From: Atmosphere CLI improvements: interactive search and install from git
My take on Atmosphere packages is basically the above. I agree with this long-term vision, and it would be really good to move towards NPM only, with security auditing and fixes that we would get for free, along with many other benefits. I also agree that making core packages and bundled tooling more independent could help the release process and allow things like Node.js or MongoDB to evolve with less coupling. We are doing this though with other modern integrated tool like Rspack, CapacitorJS, etc.
However, the effort required to reach that point is huge and could have a strong impact on the Meteor community and the migrations needed, raise your hand/like if you’re not tired of breaking changes since the Meteor 3 async transition, bundler changes, and so on. Until now, the incremental and more effective modernization path has been to keep Atmosphere packages, since they control the Meteor lifecycle well and can properly support other integrations and benefits, as happened with Rspack, CapacitorJS, and soon Rstest. Atmosphere is well-tested and mature, and in the short term we can still build tailored improvements for package discoverability, or even security auditing and fixes for our specific case, as discussed here.
With AI, we could likely move faster and more reliably at some point when dealing with the existing architecture. But I would still try to ship and honor small, quick gains around what we already have, what the community knows and understands, and make smaller and cheaper changes in terms of time, resources, and migrations.
We talk many times about reworks, but touching the architecture of an existing legacy system can be really tricky. The only way we have been able to advance over these years has been by moving piece by piece and prioritizing specific areas. Maybe after we wrap up native, testing, and other fronts, we can dedicate more effort to POCs for replacing Atmosphere with NPM. We are also very open to receiving them and evaluating a strategy for small adoption across the different cases. But this is definitely a hard task that will require strong attention. Maybe for security alone, though, it could be worth the time.
I also personally think Meteor should enter a phase where it can enjoy what has already been modernized and have time to recover its presence in the JS ecosystem. Major refactors would also take resources away from those fronts. Anyway, this is a good area for discussion and, above all, for POCs that let us play with initial implementations upfront.
