Pushing Meteor into the NPM world?

I know, that there are on-going efforts to push Meteor more into the NPM world, see the recently updated roadmap.

While I saw the big advantage to open Meteor to allow the usage of NPMs in projects without the need to write a wrapper package as it had been before, I’m not quite satisfied with the idea of putting everything into NPMs.

AFAIK Atmosphere packages provide a few advantages, which I don’t know to achieve using a NPM-only platform:

  • Tool-chain integration: It’s quite easy to maintain an Atmosphere package as part of a bigger project. The Meteor build tool takes care of it and performs a recompilation, when files change. On the other hand, many NPMs are built using their own toolchain, so changing the source needs an additional compilation step, until it can be used in the Meteor project.
  • Deep integration: The Meteor ecosystem relies on some basic assumptions, e. g. that there is a MongoDB in place. This allows the development of packages, which maintain their own collections. You can just install a package providing all the necessary database, backend and frontend code.
  • Multiple targets: Atmosphere packages allow to address multiple targets, so to provide a different code to Cordova than to the web browser.
  • Static assets: Using static assets from NPMs needs at least an additional step (like creating a symbolic link or copying them into the static folder).

I don’t know, how these advantages could be achieved by using NPM packages. It would need a specific NPM format, like for the Gatsby plugins

I just remember the yogiben:admin package as well as Meteor Toys, which were/are absolutely awesome, especially how easy they’ve been to be integrated into my own projects.

How would the transition from Atmosphere to NPM look like? What are the advantages?

If there’re good reasons to perform this transition, I’d start with a description, how such Meteor compatible NPMs should look like – maybe it would be just enough to provide the package.js on root level of the package. At least, it should provide all the nice features, that we currently appreciate with Atmosphere packages.

Maybe, such a NPM-only structure would allow to elevate Meteor to version 2.0 :wink:


So, I gave this a try recently.

The result was the Node on FHIR project, which pulls in as many FHIR related libraries as I could find on NPM, and uses as few Atmosphere packages as possible.

Interestingly, we’ve managed to almost completely disable DDP in favor of HTTP/OAuth2, even going so far as to use an Express server. We’re probably going to keep Mongo and most of the cordova build pipeline. And we’re going to need to reimplement the accounts system, which in my opinion is maybe the biggest challenge to what you’re proposing.

Regardless, the .meteor/packages file is an interesting study in what is involved in the tool-chain and what the deep integration assumptions are. While the root level package.json file is a good study in building a cross-platform client app using ES6 and NPM.

Additional details are available on StackShare.

Did something right, because the Linux Foundation picked it up for community crowdfunding. So that’s kind of cool.


I don’t think of removing all the pieces from Meteor to keep it solely as build tool, but of moving all the packages into the NPM world, e.g. a meteor-accounts-base NPM instead of an accounts-base package. As far as I understand the roadmap, this is part of it.

I just want to discuss, which steps must be taken to allow a transition without loosing any of the current features.

So, to @qnipp’s concerns…

So, if you dig into the meteor-accounts-base package, you’ll see that it relies on the mongo package, which in turn relies on minimongo, which has been partially migrated to NPM. That’s where the NPM refactor has been left off, and is currently undergoing community testing.

You’ll also find that Node on FHIR has been experimenting with the minimongo NPM release. Move that line up into dependencies, and you’ll have a Meteor app that compiles and includes the NPM minimonogo along with all the latest ES6 user interface libraries that rely on import statements.

I’d also recommend taking a look at the material-fhir-ui package, which has a working development and deployment pipeline for publishing NPM packages that run isomorphically within Meteor and Atmosphere packages. There might be other approaches and solutions, but this is the one that I’ve found to work using ES6 and rollup.

So, to do a clean migration of meteor-accounts-base, the way we would go about doing it is to start by forking material-fhir-ui, renaming it, adding the minimongo, mongodb, and ddp-client NPM packages as dependencies, and then mocking out the Accounts API from the original meteor-accounts-base package as TDD tests. And then begin refactoring.

I’m probably going to do something like this myself over the next few months; but I’m probably going to implement an HTTP/OAuth2 accounts system, rather than a DDP solution. So what I’m working on isn’t going to be a clean port of the accounts package from Atmosphere to NPM. But I’ve gotten most all of the compiling and dependencies worked out, which is half the task.

That being said, if somebody manages to get the DDP solution worked out, we’d gladly use it to forward migrate many of our existing projects.

accounts-js offers a meteor plugin btw


Ah see, that’s why we have these conversations. Yeah, that’s nearly perfect. Just saved me months of work. THANK YOU.

Need to do a bit of testing to confirm everything works, but based on everything I’m reading here, I can almost guarantee we’ll pull the accounts-js package into Node on FHIR.

1 Like

Meteor community FTW!

And then the reactive-var-std package gets us Session and ReactiveVar.

Add in random and json5 for Random and EJSON, respectively.

Got most of the pieces in place to try to work on Templating, Blaze, and the various other more complex client-side Meteor packages.

1 Like

Huh. Wouldja look at that. Now I want to submit a patch that merges/consolidates EJSON and JSON5 functionality.

1 Like