I really, really wanted to give 1.2 a change and created a new 1.2 project today. To this project, I’ve copied parts of my main app to make it work somehow on the new basis. I did not succeed and ended up with a strange message that Meteor could not find the fiber package.
The worst thing, however, is that after this failed try even my (untouched) Meteor 1.1 app (which resides in a different directory) is broken. I only get an error message now, as described in this issue: https://github.com/meteor/meteor/issues/5463 So I’m completely blocked now and will have to try to re-install Meteor completely, hoping that this will fix this issue. To be honest, I’m nearly through with Meteor, this is all so disappointing.
EDIT: At least the re-install helped. The app is back again. But I’m pretty sure I will not be touching 1.2 again that soon. :-/
Sorry for you @waldgeist but this is completly different from our experiences. I am not sure on what stack you are running but we use 1.2.0.2, fourseven:scss, materialize-sass, flow-router, blaze-layout, fast-render(-ssr), react-layout, subs-manager and picker. That works pretty nice for us.
Same for me: I was able to port my app to 1.2 in one hour without any problem. Only drawback so far: build time is a bit slower. But being able, right away, to start replacing this stupid var by const and let is tremendous :- )
I can’t tell what I’m doing wrong, I can just describe the symptoms. :-/ I’d love to know what’s going on there, but having to re-install Meteor to get rid of these strange Fiber problems did not build up my trust in the new version.
Just wanted to report: upgraded a site from 1.1 to 1.2, totally smooth experience! I just had to remove grigio:babel and add ecmascript, and change all my script filename extensions from .es6.js to just .js.
While building the application:
/Applications/ourApp/client/stylesheets/app.scss:4:9: Scss compiler error: file to import not found or unreadable:
.meteor/local/build/programs/server/assets/packages/meteoric_ionic-sass/ionic
Current dir: /Applications/ourApp/client/stylesheets/
If anyone is using meteoric ionic and got the unkillable sass import error, I found out that the import path has changed and had to change it to the new one. You have to go into the .meteor/local folder to hunt it.
As a quick fix, I pinned the version to fourseven:scss@=3.2.0 in the .meteor/.packages file and that seems to be doing the job for the moment. Sounds like changing the import path would be a better long term solution though.
Last week I bit the bullet and upgraded my main app from 0.8.3, yes 0.8.3, straight to 1.2. It wasn’t as bad as I was expecting, and most of the trouble was:
hunting down iron:router breaking changes
getting alanning:roles to work
catching a few places where a function declared in template.x.helpers() were called as template.function
somewhere since 0.8.3 this.userId() started not working where it was allowed before
But here is the thing. In between 0.5 and 0.8.3 my apps kept exploding on every update, and it was mostly because some package hadn’t been updated. So despite the package ecosystem being an initial draw, I learned through bitter experience to whenever possible not to use any third party packages and to roll my own. As you can see above, most of the pain was from the third-party iron:router and Roles. I know it would have been ten times worse for every additional atmosphere package I might have used.
This feels like a bad thing for the ecosystem, though I’m not sure how to address it. Someone above suggested that packages declare the most recent version for which they’ve tested compatibility. That might help. But as it is, I still greatly distrust using any packages because I don’t trust they will survive the move to a new version.
Thanks,
I did and it worked -Update took me to 1.2.0.2
then meteor could not find tasklist.exe until
I put the path as the first entry in the string of
paths. Now it’s working and I’m doing tutorials http://meteortips.com/first-meteor-tutorial/templates/ seems good
-What’s the best tutorial?
Thanks again - great program
@erichsu, I’m sorry that alanning:roles caused issues in your update to Meteor 1.2. We published a fix shortly after learning about it but I know it was frustrating.
As a package author I also get frustrated when there have been no functional changes to my package yet something suddenly breaks with a new version of Meteor. It’s happened twice now.
My understanding is that versioning is supposed to prevent this from happening. If upgrading to a new version of Meteor causes a package failure, that would seem to indicate a problem in the design of the package system. Or that the new version of Meteor was not properly bumped to indicate the breaking change.
In the case of 1.2, it may have been impossible to prevent because the problems were (I think) caused by switching from implicit inclusion of some core packages (like Match) to requiring explicit declarations. In that case, it seems like a breaking change in the package system itself; not sure how to mitigate that risk.
Perhaps automated checking of test suites for highly-used packages (roles is 90k+ installs) prior to each new Meteor release would be prudent. Better yet, let any package author register to be automatically notified when test-suites fail in Meteor pre-releases.
No worries about the roles package. I know it’s hard to test these things, and I suppose that’s one of the themes of this thread.
On a sadly related note, I updated to 1.2.1 and immediately all my velocity/cucumber tests failed. There is some issue with the mirror server not launching the browser correctly. I filed a bug and had to revert my repo to get things working again. (meteor --version 1.2.0.2 was not enough to get the tests working! That was really distressing.) I wish I had more time to wrestle these bugs down, but I don’t, so I have to doubly remind myself of my own rule: 1.2.0.2 is working, so don’t update if I can help it.
That sounds really unfortunate. I literally cannot think of what in 1.2.1 could have broken that, short of the version number somehow being hard coded in velocity.
@alanning - I think you’re 100% on point about the testing thing. It’s something I really want to do. Do you have time to help me set it up?
@erichsu and @alanning : I totally agree with your statements. Having a minor (!) release like 1.2 break so many packages is very disappointing and clearly shows that the packaging system needs some kind of overhaul. I think the biggest problem of Meteor at the moment is that it is lacking a decent set of core library packages that go beyond the “absolute basics”. Things like file uploading (CollectionFS), roles management and so on. Relying on the community to implement such core features won’t work on the long run (IMHO), if MDG wants to build a sustainable business model on top of Meteor. Although, of course, I highly appreciate all the effort and time that guys like fourseven, arunoda, aldeed and alanning (just to name a few) put into their packages.
@sashko, yes I’d like to help with setting up automated testing of packages prior to new Meteor releases. Seems like a CI tool like TravisCI could be re-purposed to meet our needs but I don’t know much about ci tools. Starting a new forum topic on this may be the best way to proceed. What do you think?