🚦 TRANSMISSION #6: Meteor Repo decoupling, Community member core maintainers, 1.3 Modules & Webpack 2.0

Note that in the future where Meteor has dead code elimination, making everything global to get around imports will not let you use that feature at all, since it all depends on the build tool being able to analyze your dependencies.


Oh that’s good to know. You’re talking about rollup.js right?

Cheater! :smiling_imp:

But yeah, make that a package like insecure and autopublish. Call it autoimport that way we do not need module backwards compatibility baked into the core.


That, or webpack 2. Or really any possible future system. Same goes for code splitting - you can’t split code if everything is global. This is why “why do we need modules, we just wanted faster rebuilds” is missing the point - strict imports is the thing that gives you faster rebuilds and code splitting.


Haha! Hey, I’m just trying to help people. I personally don’t like exposing stuff to the global scope.

An autoimport package sounds like a pretty good idea.


@benjamn thoughts on making it a package?

1 Like

Well right now you can do skip imports out of the box in Meteor 1.3, so maybe in 1.4 we can make it a removable package? For NPM, I don’t know how autoimport would work with NPM though since NPM is totally build around imports.

1 Like

I really like the idea of having packages expose the “old ways” if it would allow you to take it easier on backwards compatability, and move forward faster


Perhaps you guys (or someone) should write an article (or talk about it in the podcast) about the value on importing everything (if one doesn’t already exist). Eventually it’s gonna have to be addressed because a lot of people in the Meteor community have been so accustomed to using globals so conveniently.


Sounds like a great blog post to go out around the 1.3 release!


Transmission #6 if live! https://transmission.simplecast.fm/6

SPECIAL EDITION with @sashko @debergalis @benjamn

90 minutes of awesomeness! In this show Sashko and I are joined by Meteor Co-Founder Matt DeBergalis and Core Developer Ben Newman. It is long but I could not bear to cut any of it and I think you will agree, enjoy!

[ first 50 minutes ] Matt DeBergalis discusses Meteor the OSS project. Listen close as Matt shares why Meteor is blazing a new path for software developers and new plans to include the community more into the Meteor GitHub repo. << Big stuff !!

[ last 30 minutes ] Ben Newman discusses all things Meteor 1.3, including the JS Modules, Testing vs Velocity, Webpack 2.0, Hot-Module Reload, Code Splitting, and Rollup.js. Ben goes into amazing details explaining the how and why of it all, truly amazing (both the talk and his intellect).

Full-length video to be released tomorrow on youtube.


Looks like all-round awesomeness is happening in the transmission :-))


I’m relieved that you guys are not focusing on RN. It is doable already to build a Meteor app in RN. If anything, breaking out livedata and all the accounts into NPM packages would be more than enough to make it easier to build meteor RN apps.

1 Like

Just a quick question @sashko, is there somewhere that we can comment on the contents of the guide? Perhaps highlight any missing areas, gotchas, etc.?

For example: in the methods section, you suggest using mdg:validated-method but there is an issue if you have a method that takes no parameters at all, if you simply call Collection.methods.methodName.call() it will error. As the validator validate: new SimpleSchema({}).validator(), still requires an object.

Please file an issue on github!

Okay, in this particular instance it’s an issue with a package that has a GitHub repo, but what about other issues?

EDIT: And done, https://github.com/meteor/validated-method/issues/39

@Siyfion I think @sashko was referring to the github for the Guide itself. The 1.3 guide repo is here: https://github.com/meteor/guide/tree/version-1.3

1 Like

Whoops! My bad! :blush: I’m glad to see it has a repo though, that’s exactly what I was looking for. :smiley:

1 Like

This works great for migrating browserify.js global exports to 1.3 as well :thumbsup:

Not to beat a dead horse but one of the pros with using imports is seeing where that module is defined and how many dependancies a certain module has (if you’re importing a lot in one file it could be a code smell).


Has anyone listened to transmission #6? It only says that there were 35 clicks on Ben’s link, unless simplecast’s stats say otherwise?