Effect of omitting dependency versions from package.js


#1

https://docs.meteor.com/#/full/pack_use says “In general, you must specify a package’s version…”. I want to understand why.

Say I make a package called foo:bar. foo:bar has two dependencies: meteorhacks:ssr and alanning:roles. If I omit version numbers of these dependencies from api.use() statements in foo:bar's package.js file, apps using foo:bar will get something other than the most recent release of those dependencies, assuming no other added packages specify more recent releases. Is that correct? Will those apps always get the first release of the dependencies?

Here’s a test I did to investigate my assumptions. First, the important part of foo:bar:

// package.js file for "foo:bar"

Package.describe({
  summary: "Test package",
  version: "1.0.0",
  name: "foo:bar"
});

Package.onUse(function (api){
  api.use('meteorhacks:ssr');
  api.use('alanning:roles');
  // assume foobar.js has nothing interesting, maybe
  // just one console.log() statement 
  api.addFiles('foobar.js');
});

// no exports yet, just seeing what dependency
// versions add'ers of this app will get

If I meteor add foo:bar to a (brand-new, default/vanilla) Meteor app, that app gets v1.0.0 of meteorhacks:ssr and alanning:roles (even though more recent releases of both are available).

$ meteor add foo:bar
                                              
Changes to your project's package version selections:
                                              
alanning:roles   added, version 1.0.0         
foo:bar          added, version 1.0.0
meteorhacks:ssr  added, version 1.0.0

                                              
foo:bar: Test pkg

I wanted to understand how this works a little better before submitting a patch for the api.use() API doc.

I found this package.js dependency versioning behavior strange because I’m used to meteor add PACKAGE always getting the latest version of a package.