Meteor packages need to get better - Admin needs to be brought into core

I am just venting, but packages like user-accounts, user-accounts boostrap don’t seem to work right with meteor admin. In my opinion the meteor admin should be put into the core and maintained by the Meteor core team. I am used to using Django, and although it has so many less features, the admin and login stuff is bullet proof. How are we suppose to develop a production ready app with so many conflicts/bugs in packages?

Also, Meteor admin, doesn’t work with AutoForm image uploads:

I hope these packages get better and fix errors, it’s so frustrating when all the magic hides bugs from the developer. I’m just learning and hitting these road blocks takes hours.

I like it, I just want it to work out of the box.

Firstly, useraccounts:core is not meant to be used with accounts-ui, it is a complete replacement. The official useraccounts guide goes through setting up a bootstrapped themes login, and I can confirm it works with yogiben:admin.

I get your frustration, especially since I too am a Django dev, but you have too keep in mid that Django is almost 10 years old, it has taken a long time fore its core packages to develop and get to where they are today. Meteor only recently hit version 1.0 at the end of last year. The main drawback of using such a new framework is that because of its immaturity there are yet to be community wide best practises or a solid base of production ready packages to use. But luckly this is changing quickly, and I am sure things will get more stable as the framework matures and the community expands.

In terms of including packages in core, MDG have said that they are very hesitant to do so without a large amount of community demand and much design and testing. For example they announced the inclusion of react, a router and SQL support as new core packages in the next few releases. But I suspect without a huge community demand, admin will remain a community project, simply because having it as part of core would both discourage community packages and be opinionated about how to structure your app, which MDG has stated they don’t want to do.

2 Likes

Hey thanks for the reply, I’ll take a look at accounts package with admin.
I know it’s early for Meteor, I’m hoping great adoption and more community support make it
even better.

BTW, is your autoform image uploading working?

OK conflicts, here’s one area that needs to be looked at. For instance, https://atmospherejs.com/ian/accounts-ui-bootstrap-3 does not work with accounts-ui, if you have another package that includes this, the package still installs without prompting you that there’s a conflict. This is kind of a big stopper for people getting started, how I am I suppose to know that accounts-ui is not compatible with that library and useraccounts:bootstrap brings it in? There needs to be better ways to handle version conflicts. IMHO.

1 Like

Also, I still get signups forbidden when i did everything you describe… I am just going to avoid the https://atmospherejs.com/ian/accounts-ui-bootstrap-3 all together, there’s definitely a bug there.

1 Like

What exactly are you trying to do when you get the forbidden signups error? Are you able to share your repo on github so I can try to help to debug the issue.

On the topic of accounts-ui-bootstrap-3, neither it or useraccounts:boostrap include accounts-ui for any reason, if you have it added as a package you have to have added it yourself at some point. There is no interpreted programming language that detect dependency runtime conflicts. The fact that Meteor has a constraint solver for package versions is a huge plus, not even pip has that feature, you have to discover conflicts yourself.