Robbie, imagine you start learning PHP. You get to know about all the frameworks and the different versions for them, about libraries that are in common usage that get deprecated or replaced by others etc. Is there such a tutorial that would tell you “please use Symfony instead of Zend or Laravel instead of CodeIgniter”? No, because all of these libraries have their set of better and worse sides, there’s always some field or type of apps they suit the best.
The same with Meteor. There is no best set of packages someone would use today. F.e. I could point you to use Blaze Components, but I don’t really think it’s better in every usecase than let’s say Template-Extension package or Flow Components or ViewModel. It just suits my personal preferences more, but I would be fine with using any of them.
When I started learning Meteor, I dedicated around a week to fully get to know the different options from which I can build my own Meteor stack. I did my tests, checked different packages out in practice, wrote some simple apps, tweaked tutorials to use other ways of doing things. I recommend you the same thing, there’s no better way to actually understand why you chose one package over the other. And there is a reason why such a thing is important - there’s never one tool that can fit all cases the best way. You may start with one package and master it, but someday you want to write an app where you’ve got different requirements and you will simply miss the fact that a competitive tool would be better for this particular work, or you’ll hesitate to use it, because you’re not familiar with it enough.
I agree that perhaps there could be some sources where we could learn everything we need about Meteor package environment. But they will never be up to date, especially for rapidly growing environments that didn’t hit their stable stage yet, in which there actually are such sets of well-working together packages, tested in battles against particular kinds of problems.
Actually, I may write such a thing for my upcoming Boobtorial series in the form of objective comparison, but you’re sure to learn things by yourself before I release it online.
Maybe a webapp with comparisons of Meteor packages solving same kinds of problems that can be edited or enhanced by the community would be in place here. The closest to that in concept seems to be MeteorPedia.
That said, I can share with you the basic stack which I use for my recent project:
Blaze + Coffeescript + Jade + Stylus + Semantic UI + Flow router + Blaze Components + Collection2 + Autoform + CollectionFS + CKEditor