So, how do you recommend versioning these packages? Should you bump your package up a major version because it will no longer run on pre-1.2 versions of Meteor ?
For example, if you’re at 0.9.6 now (Meteor 1.1), and you go to Ecmascript, do you need to go to 1.x for Meteor 1.2 version ? Wouldn’t that necessitate maintaining the old branch to publish fixes like 0.9.7 for Meteor 1.1 users ? A fuller explanation of versioning packages across this transition would be welcome, thanks for all the great work !
Yeah, probably it would make the most sense to bump the major version, although it doesn’t matter because your package will automatically get a dependency on a special fake package called isobuild:compiler-plugin so the version solver will be able to figure things out. I think you have it basically right.
Our goal is to navigate this transition by trying to get everyone to switch to Meteor 1.2 ASAP, so that people don’t have to support multiple versions of the package.
In Meteor 1.2.x I’d love to see improvements to versioning for package dependencies. As it stands now, its behavior conflicts with the documentation, and I find it pretty confusing.
The idea is to write down the minimum set of changes you need to know about to keep your app running the same way as before. Let me know if something is not clear, or if I missed something!
The documentation could be clearer, but I think it is technically correct (the best kind of correct!)
Basically, any version number matches any version greater or equal to that number up to the next major version.
To fill in your chart:
1.0.0 matches 1.x.y
1.2.0 matches 1.x.y where x >= 2
1.2.7 matches 1.2.y where y >= 7, but also 1.x.y where x > 2
=1.2.7 matches only 1.2.7
no version number matches anything, and grabs the oldest version
In general, the version solver always picks the oldest set of packages that meet your constraints, so that you don’t accidentally get a newer version than what you are expecting. This is because newer versions of a package might contain unexpected new bugs or behavior.
But in my test, I included version 5.0.0 which installed 5.0.3, even though 5.4.0 was out. If 5.0.0 truly matches 5.x.y, then it would’ve installed 5.4.0, no? It installed 5.0.3 which is the last release before 5.1, so it seems that including 5.0.0 installs 5.0.y.
I’m curious why MDG didn’t just go with npm’s versioning system which is tried and tested (and pretty universally understood among JS devs), and also has syntax to prevent auto-updating to a breaking version.
You missed the end of my post I think. Just because a version is matched doesn’t mean it will be picked.
We have had a few internal discussions that this was the wrong way to do versioning, and that people probably expect to get the newest versions of stuff, not the oldest. I think you’re totally right in that the Meteor version constraint thing was based more on an academic understanding of what is more compatible than on what people actually would expect or want.
Links to the API docs for new stuff would be useful: these jump out at me: api.addAssets (package.js), Accounts.findUserByUsername, Accounts.findUserByEmail, react (package), react-runtime (package), getMeteorData
Not sure how practical this will be until the 1.2 docs are published, but you did ask
It’s not letting me use jsx with the new ecmascript package. Is this by design? I do not like that. Babel supports it, so at the very least I should be able to enable it, not need to go out and get another dependency.
After upgrading to rc16 it throws an error:
W20150917-15:45:54.186(-4)? (STDERR) ReferenceError: Meteor is not defined
W20150917-15:45:54.186(-4)? (STDERR) at lib/router.js:11:1
W20150917-15:45:54.186(-4)? (STDERR) at lib/router.js:150:1
The code on these lines is just: if (Meteor.isClient) {}
PS: I’m using Iron-Router
I didn’t try the previous version. The last one I tried was RC13 and it didn’t compile my bower packages. Now bower packages are fine but have an error with ReferenceError: Meteor is not defined which is located in lib/router.js file.
Here’s a snippet:
if (Meteor.isClient) {
// SubsManager package for subscriptions caching
var subsManager = new SubsManager({
// maximum number of cache subscriptions
cacheLimit: 20,
// any subscription will be expire after 5 minute, if it's not subscribed again
expireIn: 2
});
Router.map(function() {
this.route('welcome', {
path: '/'
});
});
}
There is probably some important piece of information missing from this reproduction, otherwise nobody’s apps would run at all. Is there something else in the error output, interesting packages you might be using, etc?
W20150917-17:08:20.437(-4)? (STDERR) /Users/verron/.meteor/packages/meteor-tool/.1.1.7-rc.15.1t0yv8k++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/server-lib/node_modules/fibers/future.js:245
W20150917-17:08:20.437(-4)? (STDERR) throw(ex);
W20150917-17:08:20.437(-4)? (STDERR) ^
W20150917-17:08:20.442(-4)? (STDERR) ReferenceError: Meteor is not defined
W20150917-17:08:20.442(-4)? (STDERR) at lib/router.js:11:1
W20150917-17:08:20.442(-4)? (STDERR) at lib/router.js:150:1
W20150917-17:08:20.442(-4)? (STDERR) at /Users/verron/workspace/devel/.meteor/local/build/programs/server/boot.js:242:10
W20150917-17:08:20.442(-4)? (STDERR) at Array.forEach (native)
W20150917-17:08:20.442(-4)? (STDERR) at Function._.each._.forEach (/Users/verron/.meteor/packages/meteor-tool/.1.1.7-rc.15.1t0yv8k++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/server-lib/node_modules/underscore/underscore.js:79:11)
W20150917-17:08:20.443(-4)? (STDERR) at /Users/verron/workspace/devel/.meteor/local/build/programs/server/boot.js:137:5
=> Exited with code: 8
And here are the packages I’m using:
# Meteor packages used by this project, one per line.
# Check this file (and the other files in this directory) into your repository.
#
# 'meteor add' and 'meteor remove' will edit this file for you,
# but you can also edit it by hand.
accounts-password
useraccounts:semantic-ui
iron:router
mystor:device-detection
stevezhu:lodash
matb33:collection-hooks
aldeed:simple-schema
aldeed:collection2
service-configuration
mquandalle:bower
alanning:roles
msavin:jetsetter
msavin:mongol
raix:handlebar-helpers
fourseven:scss
aldeed:template-extension
hybrid:assets
meteorhacks:fast-render
momentjs:moment
kadira:debug
meteorhacks:kadira
reywood:publish-composite
meteorhacks:subs-manager
semantic:ui
flemay:less-autoprefixer
mvrx:bluebird
mdg:reload-on-resume
percolate:paginated-subscription
useraccounts:iron-routing
mixmax:smart-disconnect
natestrauser:connection-banner
tmeasday:publish-counts
jparker:crypto-md5
verron:autosize
richsilv:owl-carousel
cfs:standard-packages
cfs:gridfs
cfs:graphicsmagick
splendido:accounts-meld
mizzao:user-status
fastclick
cwaring:modernizr
infinitedg:gsap
mcbrumagin:jquery-requestanimationframe
reactive-var
cfs:ui
practicalmeteor:wkwebview
particle4dev:cordova-fb
prasad19sara:client-debugger
We are using Flat-UI Pro in our apps. When adding the ecmascript package Meteor hangs and hits 100% cpu usage while starting. The problem is the provided flat-ui-pro.js file which is about 1MB in file size. Removing it resolves the hanging but results in no FUI JS functionality. Meaning we can’t play with ES2015 just yet…
Interesting, I wonder how you ended up with a list of packages that doesn’t include meteor-platform or meteor-base or meteor. Those are the packages that export the meteor symbol.
