Hey all, I’m working on a package called rocket:module.
I constantly find myself wanting to use libraries from outside of Atmosphere, and I think that having to wrap every outside library as an Atmosphere package is totally not ideal. I also always find myself wanting to use CJS/AMD/ES6 modules.
rocket:module aims to satisfy these wants.
It’s not released or documented yet, but basically what
rocket:module will do when finished is let you specify entrypoints using
api.addFiles in a package’s
package.js. In those entrypoints you’ll be able to use CJS/AMD/ES6 modules, and load things from npm for the client side or server side (not using
Npm.depends, but a separate config for specifying npm dependencies that aren’t limited to absolute versions like with
Npm.depends). Behind the scenes,
rocket:module is currently using Webpack to compile bundles from the entrypoints.
rocket:module will check across every entrypoint of every Meteor package in a Meteor app and code-split common libraries into a single bundle that will be loaded before all other bundles in the entire app. Any package on Atmosphere will be able to use
rocket:module in order to specify entrypoints that depend on things from npm (and in the future perhaps other places too), and those dependencies of your package’s entrypoint bundles will be shared across all bundles of all Meteor packages in your app when those other bundles of the other Meteor packages depend on the same libraries. After that’s done, perhaps we can support entry points in the application level code too.
Any opinions or suggestions? Would it be useful for you? What plans or work are already in place in the Meteor community to solve this, if any? I’d like to know what direction is already being taken, if any, so that I can work with it instead of separately from it.