Meteor Community Group

To progress engagement, reinvigorate the community and restore some of Meteor’s well deserved former glory, many of us in the community are organizing and working towards these goals.

Our efforts to pull a number of important packages under the umbrella of community maintenance can be found on GitHub under the Meteor Community Packages Org.

There is also now a Slack workspace where we can discuss our other ongoing efforts.

Please feel free to join us and contribute your thoughts and ideas. I would love to see a resurgence of this community in the coming weeks and months.


That’s awesome, thanks for taking action!


Awesome, let’s share on our social medias, we need to bring light to Meteor, Meteor still has a lot of benefits and is a very good fit for many cases. People follow people not companies then this slack is a good start to show that Meteor is not dead at all.


It’s a very nice initiative…great…

Re-posted on Minds:

1 Like

My late night procrastination somehow intertwined with the excitement over Meteor 1.8.2 just moving into the RC phase, 1.9 proceeding into beta.1, and the fact that the current logo in the Meteor Community Github repo makes my eyes bleed.

So I got all artsy partsy and sketched this logo / icon for the Meteor Community Group. Let me know if anybody likes it and I’ll happily provide an image with any suggested tweaks in the required size and format.



I am excited about the level of support being shown for this community group and also for the direction of the Meteor project itself. 1.8.2 is adding in support for TS which is a big deal and then 1.9 will upgrade Node to version 12. another huge win for all of us. I’d say things are looking up :slight_smile:


I wonder if I need a written permission from Meteor Development Group Inc. to use the Meteor logo and the space background from in this graphic, to be used freely by the Meteor Community Group? And if so, under what license can I provide this graphic? @hwillson sorry for the ping.

Lately, I’ve been checking on several famous Meteor Package, and here is what irritated me :slight_smile:

Many of them, (alanning:roles, accounts-password, and many others) are still relying on old ES5 code, with mutables everywhere (Where did all the FP’s gone ??), or worse : they’re still using that ***** of underscore or lodash dep, which I clearly don’t want in my code base and bundle size.

In addition, I’d like to be able to import the accounts packages server-side only, though I know it can be very usefull to use it client-side directly, but I’d like to have the choice in order to be able to ship client bundle that can easily get rid of DDP and solely rely on an agnostic GQL API.

I’m ready and geared up to participate and bring Meteor back to its shiny glory :smiley:


I’m not sure what exactly is so bad about something being written in ES5, and I’m not sure what you mean by mutables everywhere. Truly if a package works well and doesn’t have severe bugs, then I don’t see anything wrong with it. In most cases it’s going to get compiled to ES5 anyway so the only real issue might be having to read the code. I can certainly agree that it would be nice to replace dependence on certain utility packages that bloat a build bundle though.

Of course these are all things that you can be actively working on or trying to push for. Glad to have you with us, and I look forward to your pull requests and issue submissions.


I’ve submitted paches to alanning:roles to remove underscore, and a few others (some of the raix packages I submitted to have already been updated) - I think this is one of the reasons to set up the community repositories, so we can update and improve these common packages.

Update - er, I forgot, someone beat me to the underscore removal, so I just use that as a local package. I went on a mad dash to remove underscore from one of my projects a few months back, and submitted a bunch of PRs. Can’t remember everything!

1 Like

is the removal of underscore because lodash has supplanted it and it kind of got abandoned or is it for some other reason? like library size or a security issue?

I think most of it is bundle size. Especially when you end up with both underscore and lodash being included.

1 Like

Mostly to reduce bundle size in the modern bundle (the legacy bundle will use Babel polyfills - don’t know if those end up being any smaller than underscore)

I understand your point. A working package is of course not a priority to update, but I remember, when I started web development 6 years ago, a lot of my understanding came from opening package, wether meteor’s or not, and read it, read it read it. It might be good to keep our codebase up-to-date in this regard too.

In addition to that, I disagree with you about everything being transpiled to ES5 : since Meteor 1.8 evergreen version, two bundles are now transpiled, the modern one is able to take advantage of a more modern and structured code.

Concerning mutables, I’m thinking in particular of the alanning:role package, where function parameters are being reassigned in all direction. That’s not much because it works, but in bigger packages, ensuring a better code quality in regards of more modern and battle tested paradigms like FP is, imho, a good things to do while we’re going to update, re-maintain and modernize those packages we love, in addition to making the code more robust and easier to test.

@brianmulhall Both underscore and lodash are heavy, slow and completely and very easily replacable by native ES6+ functions (Object.assign, keys, entries, values,, forEach, some, includes, reduce, filter, etc). Even pipelines and composed functions are so easy to rewritte without needing a dependency of dozens of kb. In addition, many package and modules uses either one or the other of those big libraries resulting in the absolute stupidity of having 2 or more of them in our bundles.

@captainn Actually, for I don’t know what reason, when adding alanning:roles in your project, it loads, if I remember well, the 1.2.0 version instead of the 2.0 by default. And the underscore removal has never been merged, I also rewrotte the package locally but still, that’s not a long-term valid solution for the community imho.


Thanks for the information @copleykj and @fen747.

is the alanning:role package still being maintained?

Regarding the last commit on both master and 2.0 branches, I’d say it’s not.

When I was setting this boilerplate up I forgot about all the planning:roles nuonces and just installed it from atmosphere. I then included a local copy from the PR which removes underscore, which I think may be against 1.x. At some point I’ll go back and update it, but I’m hoping the community port is out before I do that.

I almost forked it myself at one point.

Ill add that a list of packages with a high number of installations that need a maintainer, when i get up to about 20 or so candidate packages ill post it to the forum for people to weigh in on

It’s in the process of being moved under community maintenance.