Advice for building a Meteor Moment Js helpers package


#1

Hi, First post to the new forums and I would love some advice on building a Moment Js helpers package.

Package: https://atmospherejs.com/lbee/moment-helpers

What it Does: It makes it easy to use something like {{moFormat myDate 'YYYY-MM-DD'}}

Question: Should I specify a momentjs package? eg. api.use('momentjs:moment@2.9.0'); or advise users to ‘bring your own moment js’

Context

  • People use different moment js packages, even though there is an official one, there are still valid reasons for using the non-official package. https://atmospherejs.com/?q=moment (even the old mrt version still has 8.5k installs)
  • I have seen the pattern in other helper style packages, eg. https://atmospherejs.com/useraccounts/ionic has a section in their docs about ‘Bring your own ionic’
  • I have just run into the frustrating locales issue (forum link below), someone has submitted a Pull Request that utilises the locales feature and I want to merge it in & make it work but I do not want to require a moment js package that is not standard or may be languages not everyone needs.
  • I want to avoid people having multiple moment packages being sent to the client but also aware that this will be a breaking change for existing users of this package (not many as yet).

Thanks in advance for your advice, and any links to where this is already covered would be great (I did a search but did not find anything too useful).


App packages and packages dependencies
#2

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.


#3

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.


#4

@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.


#5

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.


#6

Brilliant. I will play around with that


#7

Hi @lbee how did your work turn out? Could you accomplish what you’re after?

Also, you might be interested in this thread:


#8

Delaying until the next chance I get to sit down and take a good look at it, will check out the post thanks


#9

@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.


#10

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.


#11

Out of curiosity, does anyone think this package could be added under the momentjs namespace?
…something like momentjs:helpers?

This would obviously mean the only dependency could be momentjs:moment :wink:


#12

Do you mean embracing this as an official momentjs package exlusive for meteor?


#13

yes, more or less

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! :smile:


#14

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.


#15

We’re trying to do something towards this direction as a community on MeteorPackaging: feel free to open a new issue among the discussions


#16

@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.

Also, I have submitted my first package (for lunr.js) to your meteor packaging discussion: https://github.com/MeteorPackaging/discussions/issues/28

@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.


#17

Lets see how much interest this is going to get…
But if well reasoned I’d say ti would be a good package to have under the momentjs namespace :smile:


#18

@splendido question: should I start a new issue on my repo for this or ask the question on MeteorCommunity discussion: https://github.com/MeteorCommunity/discussions/issues/14

regarding moving to the momentjs namespace


#19

@lbee I’d open an issue on MeteorPackaging/discussions
to then create a new repo on MeteorPackaging.

Could you please list all features you would put into it? So we can see what people think about it?


#20

Will do @splendido thanks