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
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.
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.
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.
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.
