Isotope discussion Program3r <-> dandv

[dandv]

Hey @Program3r, let's move this discussion here, since it got quite specific.

Here's my package code for bundling up and testing Isotope

To be honest, I've read through docs.meteor.com and Differential's dissection of the Package api and don't understand exactly what versionsFrom does.

If no version is specified for an 'api.use' dependency, use the one defined in [parameter]

That doesn't suggest that if a package has api.use('0.9.0'), it can't be used with newer Meteor apps, as you seemed to imply:

Thanks for upgrading your (from official) package to 1.0 so it can be used in new meteor apps.

[Program3r]

I just re-tested this and it was an issue with my (docker) container. I created a new one and was able to use 0.9.3 packages in a 1.0 application. versionFrom is supposed to control what core packages are loaded based on that version of Meteor you lock in. I assumed from the behavior of my container that it was locking applications to the version of that package by not resolving versions correctly. I've since violently deleted that container. I don't have the issue anymore.

[dandv]

"violently deleted* :-)

1. Is it accurate that if there are no api.use() calls in a Package.onUse() then, api.versionFrom is irrelevant?
2. Is it accurate that api.versionFrom() only impacts api.use() calls for core packages?

[Program3r]

1) I wouldn't say it's irrelevant completely, if an a API of a core package gets changed that you didn't specify with api.use() (or use versionFrom instead) but are using anyway (like jquery/spacebars/blaze) then your application would use the new version right away when your package is used in an updated meteor install. It could cause things to break.

2) Yes, it only impacts core packages.

[dandv]

Thank you. Let's say jquery is used. What versionsFrom parameter would ensure compatibility with the largest number of current Meteor packages? Maybe specify all of them, as autoform does?

api.versionsFrom(['METEOR@0.9.3', 'METEOR@0.9.4', 'METEOR@1.0']);

[dandv]

Actually an explicit METEOR@1.0 causes breakage on Windows.

package.js:

Package.onUse(function (api) {
  api.versionsFrom('METEOR@1.0');
  api.use([
    'jquery',
    'twbs:bootstrap@3.3.1',
    'fortawesome:fontawesome@4.2.0'
  ], where);

C:\prg\met\test>meteor add summernote:summernote
Could not satisfy all the specified constraints:
Error: conflict: constraint jquery@1.0.1 is not satisfied by 1.0.1-win.0.
Constraints on jquery come from:
  <top level>
  meteor-platform@1.2.0-win.0
  meteor-platform@1.2.0-win.0 -> blaze@2.0.3-win.0
  summernote:summernote@0.5.10

C:\prg\met\test>meteor add summernote:summernote@0.6.0
Could not satisfy all the specified constraints:
Error: conflict: constraint jquery@1.0.1 is not satisfied by 1.0.1-win.0.
Constraints on jquery come from:
  <top level>
  meteor-platform@1.2.0-win.0
  meteor-platform@1.2.0-win.0 -> blaze@2.0.3-win.0
  summernote:summernote@0.6.0

If I change package.js to api.versionsFrom('METEOR@1.0'); then the package installs fine:

C:\prg\met\test>meteor add summernote:summernote-compat
   added summernote:summernote-compat at version 0.6.0
   added twbs:bootstrap at version 3.3.1
   added fortawesome:fontawesome at version 4.2.0

summernote:summernote-compat: summernote (official): jQuery+Bootstrap+FontAwesome WYSIWYG editor with embedded images support

The magic bullet seems to be

api.versionsFrom(['METEOR@0.9.0', 'METEOR@1.0']);