Wow, first of all, I congratulate you from the bottom of my heart for asking this. This has exacly been the reason why I’ve been avoiding some packages from atmosphere.
Some package authors just pin down a dependency to a version and never update it, causing your whole app to suffer from that.
I think, if you really depend on a specific version of moment.js, than of course you should do that and also make a note in your readme.
But otherwise, you can and believe should go with “bring your own moment” style.
Thanks for that, I like the approach of dependencies being real requirements, and in this case mostly any version 2+ of moment js will do.
I did not even think about the updating but that definitely has been an issue with me (even logged an issue on a package today for that very thing with an autoform package dependency).
Yes, I will ensure the docs reflect this change / approach.
@serkandurusoy any direction on how to implement this, if you do not include the dependency Meteor does not load the packages in the correct order & I run into errors because moment doesn’t exist.
If I interpret this http://docs.meteor.com/#/full/pack_use correctly, you can use the weak option to tell meteor that you are going to be using moment if it is there and you don’t explicitly need it.
That should, in my opinion, give you the chance to build the package, but not include it as a dependency, allowing others to include theirs.
But I also think you also need to suggest a minimum version nonetheless.
@serkandurusoy I looked into the weak dependencies, it did not help, I kept running into test issues with this approach, I would be great to have some way to test situations where different packages are included or not. I might post to that thread with some additional thoughts.
Thanks for your feedback, I am just about to push the latest version of the Moment Helpers package with the ability to put in custom functions to your formatter, I would love your thoughts on this.
I have a project coming up where I’ll be dealing with time related inputs and display as well as multiple timezone support. I’ll definitely give your package a go.
I’m sorry to hear about weak dependencies.
I have an idea, but have not tried it. Since package.js is basically a javascript file, you could try checking the presence of another moment package by querying the moment object and including yours depending on that check. It would look something like:
if (!moment) {
api.use(moment@x.x.x, [client,server])
}
You might need to decleare a weak moment dependency before executing this check, though.
we already have momentjs:moment and momentjs:twix (and perhaps others coming…).
Why don’t add a momentjs:helpers with weak dependencies on all others to provide out of the box Meteor helpers to be used with Spacebars?
The package form @lbee seems a very good starting point!
that would be awesome not only due to its content but also because it
provides a sense of direction and a feeling that the package is vetted
therefore safe to use.
@splendido thanks for the compliment, It is my second package I have pushed to Atmosphere, good to see it is getting some use. Not sure how it would roll out - but keen for it to change namespace if that makes it easier for people. How would I go about requesting that.
@serkandurusoy I have reopened the issue for ‘BYO moment.js’ and will mention your suggestion about the package.js approach, however I think I could do this very differently and simply not depend on any version of moment.js (except in tests), I can then check that moment exists when the helper is being used (my initial attempts, checked when the package code was loaded, hence why I think I kept getting errors).
Would love your additional thoughts here: https://github.com/lb-/moment-helpers/issues/15
Thanks everyone, I am loving Meteor and the chance to support the community where possible.
