Getting rid of autopublish and insecure by default when a Meteor project is created

core
1

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 insecure and 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.

Thoughts?

8 Likes
2

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.

And even this could be covered, for example if we have a meteor create --beginner that is optimized for first use and could also contain autopublish and insecure but yeah, I agree that the default should be the secure config (silently pointing to allow / deny).

4 Likes
3

I believe we should do something similar about denying writes to the profile field on user documents. Again, we should prioritize security and production standards.

1 Like
4

I think it’s a fine idea to provide a variety of templates, and maybe have a --beginner keyword.

When I teach Meteor, though, I provide my own custom template for students. It does use insecure (that does simplify things) but also adds React, Uniforms, ESLint, etc:

I think it’s important to note that there’s a lot more to building a “production” app than the presence or absence of insecure. For me, that’s actually a relatively minor issue. Clever Beagle has a product that illustrates many of the additional considerations to get a Meteor app into the realm of “production”:

There will always be newcomers to Meteor and web application development. Figuring out the pathway that enables them to get started quickly but keeps them aware of the compromises that are made in the course of bootstrapping their skillset is very complicated.

2 Likes
5

This sounds like a Hacktoberfest PR. :point_left: :point_left: :wink: :wink: