I was wondering what we could do as a community to prevent scenarios such as this one:
I need moment in my app so I add the momentjs:moment (“official”) package.
I also need to have simple forms based on schemas and add aldeed:autoform and another autoform package for datetimepicker that also uses moment but the mrt:moment package.
This means that in the files sent to the client, I will have moment two times right ? Conflicts and unexpected behaviors are therefore happening.
The solution I found myself forced to use was to remove the momentjs:moment and add the mrt:moment in my app, which I didn’t mind. But the momentjs:moment package had a newer version of moment, I can see people needing to keep this package if they use new API functions.
How can we prevent such a scenario ? Ask the timepicker package manager to change his dependency ?
Are “weak” dependencies the solution ? I find that the tutorials about package editing are not so clear and could be improved and some even contain bad practices.
What I would like are stronger guidelines on package creation, like the discussion Dan Dascalescu had on github.
Unfortunately, this is an ongoing discussion (check this out Advice for building a Meteor Moment Js helpers package) that does not allow MDG or any governing body to intervene.
The package ecosystem is open and we as the developers are the strongest mass that can actually push change for the better.
Your options are:
- Stop using that datetimepicker package and notify the author that you’ve done so for reasons as such
- Fork the package, fix its dependency and send in a pull request to the author explaining the situation
If these don’t work out, that they do not respond to pr’s or issues on github, you can always call out their names on the forum and crater.io hoping you’ll get their attention and attention of those other users of those packages.
If none works, you can opt in to publish your fork of the package with correct dependencies.
It should all start with an official issue on their github repo by the way so that the problem is known to anyone who cares.
I used moment as an example as it is a super popular library but this could be the case for many other packages.
And yes, many discussions are going on right now to get the best practices and I love the Meteor Packaging initiative, this is what makes this community awesome. But I would like to let out a cry out to the MDG or the atmosphere team to really set everything straight so we have an “Official official” way to do packaging because now people are just making packages like they want without really taking care of it afterwards. I am sure I missed some threads about this.
But maybe this is just for now, to blow up the amount of published packages to attract people that are impressed by big numbers.
What happens to a package once it has been flagged on atmosphere ? How many flag click does it take for it to be marked as not working ?
What happens to a package once it has been flagged on atmosphere ? How many flag click does it take for it to be marked as not working ?
“10% of downloads of a version and status get reset if a new version gets published” as taken from Flagging feature on Atmosphere considered harmful
Also, a few people from MDG have previously posted succinct replies about the matter. Their basic premise is around the community being able to use the already available features (flag/star/download) for bubbling up high quality packages and that imposing package publishing restrictions would conversely undermine the ultimate quality goals by making it hard for people to contribute.