[SOLVED] When to use api.versionsFrom in local packages?

help
1

I’m looking for any/all recommendations on api.versionsFrom. Thanks!

I’ve got some local packages (the app is using METEOR@1.3-beta.11) that have things like

  api.versionsFrom("1.0.2.1");

in their package.js. Does that mean that even though I’m in Meteor 1.3 these local packages will use the versions of Meteor packages from the older release? What are the implications, considering the app is on 1.3 (beta.11)? When should we use / not use api.versionsFrom?

The reason I ask is because I’m tempted to remove all api.versionsFrom calls in local packages and bring things up to date (I assume no api.versionsFrom call means use the latest package versions unless otherwise specified on a per-package basis).

The api.versionsFrom calls in the app are somewhat varied:

 ❯ grep -EHrn "\bapi.versionsFrom\b" ./ 2>/dev/null | grep -v \.meteor | grep -v \.git | cut -d: -f3 | sort | uniq
  api.versionsFrom("0.9.0");
  api.versionsFrom('1.0');
  api.versionsFrom("1.0.2.1");
  api.versionsFrom("1.0.3.1");
  api.versionsFrom('1.1.0.2');
  api.versionsFrom('1.2.1');
  api.versionsFrom(['METEOR@0.9.4', 'METEOR@1.0']);
  api.versionsFrom("METEOR@1.2.0.2");
  api.versionsFrom("METEOR@1.3-beta.11");
2

Hey :slight_smile: versionFrom affects core packages (i.e. those without an author namespace prefix) that don’t have versions specified. In those cases, it will use - as the minimum semver version (and using the default version solver logic to maintain compatibility) - the version for that package as specified for that Meteor release.

I.e. if you have

api.versionsFrom("1.0.0");
api.use('underscore');

and the Meteor 1.0.0 release used underscore v0.5.0, this would be the equivalent of having said:

api.use('underscore@0.5.0');

That doesn’t lock it to 0.5.0, but rather specifies 0.5.0 as the minimum version required by that package. Meteor will use at least the highest minimum version specified by all used package (assuming they’re all semver compatible), and possibly later if e.g. specified by your project / via meteor update, etc.

By default, Meteor avoids updates that aren’t necessary, to avoid potential breakages.

The api.versionsFrom calls in the app are somewhat varied:

METEOR is the default release track… so the following two lines are equivalent:

api.versionsFrom("1.0.0");
api.versionsFrom("METEOR@1.0.0");

When an array is specified, this applies downwards to packages too, meaning that either spec’d version is ultimately ok, and the package contains any necessary logic to work correctly with either version.

When should we use / not use api.versionsFrom?

At the end of the day, it’s just a convenience. It’s no difference from manually specifying the associated package versions for a particular Meteor release.

See also http://docs.meteor.com/#/full/pack_versions (which I just looked up now, and is perhaps a slightly briefer description of the above).

3

@gadicc to the rescue! Thanks! :} For sure. Well, some packages in a 1.3 app were relying on core packages from (0.9.0), like templating. Seems like eventually packages could get outdated enough that they’ll possibly eventually be loading conflicting core libs (similar to how it’s not a good idea to mix components from different versions of React), possibly semver incompatible versions, so I figured maybe it’s better to avoid the growing range of versions in the versionsFrom calls. So, in the transition to Meteor 1.3 I removed all versionsFrom calls in all the local packages, so they use the Meteor release. All is working. We’re also working on a new testing workflow based on Meteor 1.3’s recommendations, so that will hopefully catch possible (unlikely, but nonetheless important) errors when updating Meteor releases (besides catching or own errors).