Public release candidate of Meteor 1.2

[sashko]

The difference is in rebuild times. If you have a big app with a lot of less or HTML files, you should see a dramatic improvement in the refresh time when you change one file.

[Ben]

Ok, then something is probably wrong. It takes ages to (re)build. Minimal just as long as 1.1, maybe even longer. Especially the time it takes to pick up a “change” in a file before the rebuild is triggered is longer. Anyting you know of I can check to find the cause?

[wursttheke]

Do you, by any chance, use the semantic:ui package? It internally uses https://github.com/flemay/less-autoprefixer, which does not (yet) make use of the new build strategy. So it goes through every css file on every rebuild which is painfully slow.

[Ben]

Good catch! I used to use that package. But I figured that might be a source of the slowdown, so switched to semantic:ui-css instead. I also switched back to the default less package. So that shouldn’t be it anymore.

For completeness, these are the packages I currently have:

standard-minifiers
meteor-base
mongo
blaze-html-templates
session
jquery
tracker
logging
reload
random
ejson
spacebars
check
ecmascript
email
accounts-password
accounts-base
less
aldeed:collection2
cfs:s3
cfs:graphicsmagick
cfs:filesystem
cfs:standard-packages
reywood:publish-composite
alanning:roles
momentjs:moment
rzymek:moment-locale-nl
anti:fake
aldeed:simple-schema
tap:i18n
reactive-var
lepozepo:accounting
d3js:d3
harrison:babyparse
peerlibrary:blaze-components
aldeed:template-extension
tmeasday:publish-counts
meteorhacks:kadira
kadira:flow-router
kadira:blaze-layout
pagebakers:ionicons
semantic:ui-css

Any other troublemakers people recognize?

---

To add, after pressing “save” on any html file in my project, it takes about 10 seconds for the terminal message “Client modified – refreshing (x8)” to switch to “x9”. Is that normal?

[timw]

RC 15 is now out, contains an important bugfix for running on android devices.

[bwhitty]

I’m also seeing slow rebuilds, not in the actual build time but in the time it takes for Meteor to start rebuilding. When I save a client-side file, it consistently takes 20-23s for Meteor to start rebuilding. Server-side files take 10-13s to trigger a rebuild. I do see a Node process spin up my CPU list immediately upon saving, but the cli takes the aforementioned amount of time to start updating (and thus the rebuild, and refreshing of browser, etc). This is running Meteor METEOR@1.2-rc.15.

[deanius]

For those always wanting the latest & greatest:

meteor update --release $(curl -sL http://bit.ly/latest-meteor-12-rc | sh)

This and a few other tips in this article. Would love your feedback - a few edits are already underway thanks to tips from all of you.

[deanius]

Packages that depend on Meteor 1.2’s versions of coffeescript, less, stylus, or templating, or that use the new ecmascript or static-html packages, will only work with Meteor 1.2 or later

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 !

[sashko]

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.

[ffxsam]

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.

[sashko]

Breaking changes in Meteor 1.2 document

Please help me proofread this document I’ve put together on the wiki about breaking changes in Meteor 1.2: https://github.com/meteor/meteor/wiki/Breaking-changes-in-Meteor-1.2

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!

[sashko]

Where does it conflict with documentation?

[ffxsam]

Package version numbers highly confusing

The Meteor documentation says: In general, you must specify a package’s version (e.g., ‘accounts@1.0.0’ to use version 1.0.0 or a higher compatible version (ex: 1.0.1, 1.5.0, etc.) of the accounts package). If you are sourcing core packages from a Meteor release with versionsFrom, you may leave off version names for core packages. You may also specify constraints, such as my:forms@=1.0.0 (this package demands my:forms at 1.0.0 exactly), or my:forms@1.0.0 || =2.0.1 (my:forms at 1.x.y, or exact…

[sashko]

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.

[ffxsam]

• 1.0.0 matches 1.x.y

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.

[sashko]

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.

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.

For much much much more detail about the issue, see @dgreensp’s post on Hackpad: https://meteor.hackpad.com/Packaging-UX-Gravity-Hurts-FoTnLTVUklt

(For context, David Greenspan is the person who actually wrote Meteor’s version solver)

If you want to discuss more about this topic it’s probably best to take it to a different thread.

[robfallows]

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

[rozzzly]

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.

[sashko]

@rozzzly you need to add the jsx package. The idea is that you can use different packages for compiling JSX and JavaScript if you want.

If you don’t want, feel free to use the old Babel package.

[verron]

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