Check out the README: https://github.com/meteor/meteor/blob/master/packages/ecmascript/README.md
Oh! Thanks, thatās exactly the kind of thing I was looking for. A link to that from the Meteor docs (and the upgrading to 1.2 guide, for that matter) would be really helpful.
Using 1.2. Great step forward. Havenāt really had issues at all and we have a big app with lots of packages.
Package lag is to be expectedā¦constraint solver helped me ā¦Most packages are compatible but Iāve had issues with fourseven sassā¦ wish mdg gave sass the same amount of love as less and stylus. The fourseven contributors are great but slow because they other commitments
on meteor 1.2ā¦
I try this:
meteor create myproject
cd myproject
meteor add accounts-password
meteor
working well on localhost
then i try this.
meteor deploy [myapp].meteor.com
the deployment to meteor.com failed. but if i remove account-password package and run again
meteor deploy [myapp].meteor.com
it work well!!.
any idea why this happen?
I try with meteor 1.1 previously is working well for all step
Hi, can I know how you revert from 1.2 to 1.1? tq
I started a new app when 1.2-rc.12 was out because I was going for the React / ES2015 features, but I half wish I was on 1.1. The build times are crazy slowā¦ 20-30 seconds for client file modifications, which is a killer for development speed. Issue is here: https://github.com/meteor/meteor/issues/5269#issuecomment-144776937
Still on 1.1 for all my production apps because Iāve read a lot of posts in the forum about things breaking. However I will be trying 1.2 for any new projects.
@hellstad: Wise decision. Just dared to do an update to 1.2.0.2, and now not only my SASS files were broken, but also Mongol and Jetpack threw exceptions on startup. Itās really sad and costs such a lot of time googling around for workarounds. :-/
To save you some Googling:
-
In
/.meteor/.packages
and/.meteor/.versions
, replacefourseven:scss@3.3.3_1
withfourseven:scss@3.2.0
-
Use Constellation until Mongol/Jetsetter gets a bugfix release
@babrahams: Thanks for the info. Already did the scss downgrade to 3.2.0, but wasnāt aware of Constellation.
ok not sure what is up with the reply function on here, but re: rolling back - this worked for me:
meteor update --release 1.1.0.3
Whenever some package under Meteor 1.2 uses the less
module without an explicit version number, it is resolved to the most recent version ā 2.5.0.
All the while, Iām maintaining two major projects which are stranded on Semantic UI 1.12.2, because Semantic UI 2.x introduced a wide selection of breaking changes that are incompatible with the theme Iām using.
Alas, this semantic:ui
version of yesterday requires less
in version 1.x, which makes the entire update fail
Like @danancona said. But if I remember right I had to remove some 1.2 specific packages and re-add some packages from 1.1.0.3. Unfortunately Iām not sure which one.
The main problem was materialize:materialize. With updating to 1.2 I fetched 0.97.1 which is generally broken in Meteor (even in 1.1.0.3). I had to revert this package to 0.97.0 (I had to do it in the .meteor/packages file.)
Iām using 1.2 with a side project iām doing with react.
But for my main app in production which is 100% blaze, i donāt really see the point in upgrading to 1.2 for now, with all the possible incompatibilities, and no real added value, at least for me.
I will probably upgrade when some time has passed and all rough edges have been resolved by other than me
The real incentive to upgrade for me will be ES6 modules, which is really life changing (thank you, meteor-webpack-react !)
I need to keep on with a āworking productā without breaking changes. Once all package dependencies will be explicitly upgraded to 1.2 iāll proceed.
Thatās right, things like Windows support, Angular and React can help to attract developers who are new to Meteor, or developers who use those platforms somewhere else and want to use them with Meteor. But those things do not help developers who are already using Meteor with Blaze, etc.
It would be nice if the Atmosphere entry for a package would have a field showing which Meteor release the package has been tested with. At the moment it is kind of hard to tell.
Not sure if this is 1.2 related but: I finally did upgrade to 1.2 after figuring out the problem was with the materialize package and that rolling just that back worked. But now Iām having awful slowness with meteor deploy, itās taking ten plus minutes in the āuploadingā phase. And Iām on day 3 of getting spiderable to emit opengraph tags; thatās been a nasty surprise for something that I thought (based on experience with other frameworks) would maybe take 20 minutes. Pretty frustrating all around.
if you are using source code control, rollback is no problem