This has been brought up in the past, but now that Meteor is under new management, I think this needs to be addressed again.
For most of us who use Meteor in production, one of the first things we do is remove the
autopublish modules. In fact, this is recommended practice for production development.
So, why don’t we use make this the default case and remove these packages from the defaults when a new project is created?
I can see why it made sense in 2012-13 to show the magic of Meteor and how it just works out of the box and getting people familiar with frameworks, but in 2020 there’s a lot more maturity and competition around JS frameworks, and for Meteor to be considered a serious player, it should default to what is best for production, not for tinkering or just getting started.
IMO it should be secure by default, and not an opt-in.
I’d suggest making the defaults more aligned to the best practices in the Meteor Guide. It just makes sense to have it production-ready by default.
The other issue I have is that leaving these two packages in tends to lead to lots of tutorials using them to teach Meteor. But in reality, none of us use these packages IRL. So, a lot of introductory learning is teaching a pattern that isn’t usable for actual project development.
I understand that it’s a function of keeping the tutorials simple and short which Meteor is great at (Twitter clone in 45 mins anyone?), but it’s a bit of a disservice as you’re creating a bit of a confusion in what you’re teaching and how you WOULD use the same knowledge in the real world.
At a larger utility level, the tooling should optimize for real-world use and not first-time use. The current design is a hangover from the early-days IMO for promoting tinkering and easy to get started.