semantic versioning violation breaks load order and --production run fails with weak dependencies (I think)

[igoodrich]

Hello Nemo. Thank you for making and maintaining the package. 👍

I am trying to use meteor-bootstrap with accounts-ui-bootstrap-3 (https://github.com/ianmartorell/meteor-accounts-ui-bootstrap-3). It works great in development mode, but not when meteor --production is used to run it, nor on modulus without a -D (debug) flag. '-D' with modulus means 'Debug' and the minimization if skipped.

You can see here (https://github.com/ianmartorell/meteor-accounts-ui-bootstrap-3/blob/master/package.js) that that accounts-ui-bootstrap specifies it's nemo64:bootstrap version thusly:
'nemo64:bootstrap@3.3.1_1'

Your current version is '3.3.1_5'

According to this:
https://meteorhacks.com/meteor-packaging-system-understanding-versioning
I think 3.3.1_5 is < 3.3.1_1 because the '_5' is A-Z sort < _1 -- if I'm reading the above-referenced depiction of versioning correctly.
accounts-ui-bootstrap-3 specifies the dependency weakly because one can also use twbs:bootstrap. That's why meteor does not raise an error and quit -- it's a soft dependency.

In essence, the '_5' may be undermining the packaging system's ability to correctly order dependencies. In fact, nemo64:bootstrap is after accounts-ui-bootstrap in .meteor/versions. I assume after means to be loaded after (I am not certain though). For some reason, this does not matter w/o the minification that --production brings.

I would have tested this and done I think that means I'd have to actually fork first and re-publish the package under my name -- so, I decided to raise it with you via an issue and get your thoughts. I may still do that in parallel...

Thanks!
Ian

[emgee3]

Hey @igoodrich, I've been helping maintain nemo64's bootstrap package.

In the version number x.x.x_y the _y is referred to as a wrap number, for packages that wrap 3rd party libraries, so it allows me to fix a bug while maintaining the full version of the upstream library. Bootstrap is currently at 3.3.5, thus the last release was 3.3.5 and when I fixed a bug in my code, I bumped it to 3.3.5_1. This practice is tersely explained here: http://docs.meteor.com/#/full/packagedescription

If I were to guess at what's happening, It looks like the accounts-ui-bootstrap-3 package you're using only uses a weak dependency if the version of nemo64:bootstrap is 3.3.1, which is very old. I suspect the fix would be updating accounts-ui-bootstrap-3 to api.use a broader range of versions available. See http://docs.meteor.com/#/full/pack_use

Hope this helps!