Some thoughts about state of the packages/modules/build system in Meteor

Hi everyone,
we know that MDG has invested a gazillion of man hours in the development and constant refining of the Meteor packages/build system so far, with each version bringing big improvements, notably on the performance front.
However, this “system” is still lacking IMHO many important features.

Here what comes to mind (feel free to suggest more) :

  • no module (CommonJS/AMD/ES6) support
  • no npm support in the browser (which makes “isomorphic” programming, or whatever you call it, difficult)
  • no custom build support (i know there are workarounds involving multiples projects, but this is complicated and feels a bit hacky)
  • no incremental/on demand loading
  • no possibility (afaik) to replace packages dependency for testing
  • no dependency injection (related to previous point) support.
  • bad compatibility with other systems which consider scope differently (Typescript/NPM)

I don’t want this to be received as a criticism for MDG. Even with their ressources, i think they cannot solve such challenges by themselves.
I have been wondering in the past if MDG was too often falling in the trap of trying to reinvent the wheel.

Last weeks we were presented with the experimental project to use Webpack to replace the Meteor build system.
After playing a little bit, it seems to me this solves every Meteor problem (at least on this subject).

I know MDG is currently working/intending to work on ES6 modules integration.
I guess it must be tricky to do.

So wouldn’t it be better to “fold” Webpack into Meteor, write a Webpack loader for actual (legacy?) package system, write an “everything work out of the box” wrapper for Webpack so that beginners don’t have to fiddle with this rather powerful-but-complicated system and then move to others problems ?

What do you think ?

1 Like

()()()() Anyone ? ()()()()()()

Imho, this is the most major lacking of meteor currently. I’m sure they’re working on it, it should be supplied out of the box