What's blocking you from updating to Meteor 1.2?

core
50

Seems like I can’t get POST request body with iron-router - another guy has the same issue (https://github.com/iron-meteor/iron-router/issues/1449) - thoughts?

51

I have created a 1.2 update branch, but before I did that I cloned my app into an entirely different directory just to be sure that I always have a working version of my app in the original directory. So now I am running my app twice – the original version works and the 1.2 version had stuff break that I’ll slowly work through. Now I just switch directories to move between the two versions instead of merely checking out the new branch, which I was afraid wouldn’t be smooth.

52

That’s just not worth the effort. Stick with 1.1

53

1.2 has a different architecture for the build system which is going to enable some serious improvements in 1.3 and beyond. I’d suggest making the effort to switch now unless you want to be using 1.1 forever.

54

Hi @sashko -

Main reason we can’t upgrade our projects (which are all mobile) to 1.2 is WKWebView. The only working solution we’ve found is this one and it isn’t yet compatible with 1.2:

From the issue above it looks like there are a lot of others waiting on this as well.

Jamie

1 Like
55

@sashko: Sorry, but if I’m reading this, I can just think: you’re kidding me…?

Gave Meteor 1.2 another try today, on a brand-new app - just do run into the next problem I did not expect: How to share local packages between Meteor versions?!

That even a deprecated declaration in a non-used package breaks the whole build process is - ehm - just crazy.

Running 1.2 was such a frustrating experience to me so far, that I even think I will hard-force my new app to 1.1 (to prevent the package problems mentioned in the link) - and try to not touch 1.2 again that soon. Maybe I’m just too dumb, but all these breaking changes are driving me mad.

3 Likes
56

Just another sample, before I finally go to bed: I’ve used mquandalle:bower heavily to download packages including SASS files for frameworks that aren’t available as Atmosphere packages yet. These files are stored under .meteor, since this is the place bower installs its componnents.

But after the upgrade to Meteor 1.2, there is no way to reference these files any more, since the new cross-package referencing scheme does not allow to reference files that are located under .meteor (at least this is the situation with fourseven:scss now, I’m not sure if that’s a general limitation of the build framework. I have no idea how I should fix this, since the Bower way was the only way to get some of these files into my app.

57

@sashko does anything need to be done for packages to take advantage of caching in the new build system?

58

The build plugin that the package uses, must have implemented caching via https://github.com/meteor/meteor/wiki/Build-Plugins-API#caching. This is the case for all compilers that MDG maintains. For third party packages you can look in the source code for “caching-compiler” to find it out.

59

Alternatively, maybe MDG needs to bake 1.2 a bit more, and make sure there are appropriate utilities and upgrade paths for upgrading existing apps (looking at Sideburns here).

Now that 1.0 is released (as well as Galaxy), MDG has a culture shift that it needs to manage. And I’m not talking about younger populations of developers who are using whatever latest-and-greatest shiny tech that’s currently in vogue, be it React or Angular. But with established businesses who want to bring their systems into production, keep them there, and are willing to pay the Galaxy support fees.

Compared to other big platform companies like Microsoft and Oracle and Apple, Meteor is proceeding at a blistering pace. I started using Meteor in 0.5 days, and basically every upgrade ever published has broken my apps. Some of us aren’t into the perpetual upgrade cycle breaking our apps.

Clinical Meteor is only just now upgrading from 1.0.4 to 1.1, because everything has been working pretty seamlessly. And we’re not slated to finish the upgrade to 1.1 till the end of the year.

So, the earliest it will upgrade to 1.2 is probably Q1 of next year. And that will only be so we can get the AccountsServer and AccountsClient API, so we can get single-signon across multi-tennent apps. The benefits of the rest of the build system changes haven’t been established, nor have they been real-world tested enough.

2 Likes
60

Hi @waldheist

I am not sure what problems you are running with on fourseven:scss but we use it in conjunction with poetic:materialize-sass without any issues since last update @3.3.3_3. Check the update of https://github.com/poetic/meteor-materialize-sass/commit/74a8978ed534f1f7ffe6ad384df9de7374638b16 for example, maybe it gives you some help on referencing files.

We have waited until Meteor 1.2.0.2 and have now upgraded 3 apps from us which work fine after some modifications. It doesn’t take us longer a day each and some patches to relevant packages.

Also the porting of the universal fork for arm architectures is pretty stable and running our apps on that devices are now without issues.

Just my 2cents
Tom

1 Like
61

Hi Mark @mrw34

you may build the correct node yourself when using the meteor git once:

git clone --depth 1 -b release/METEOR@1.2.0.2 https://github.com/meteor/meteor.git

cd meteor

scripts/build-node-for-dev-bundle.sh

You get a tarball after that with a portable node v0.10.40 package

Just extract somewhere to your system and use that for node and npm on your production environment.

Maybe you need some tools to compile that sources. At debian based distros these packages are:

apt-get install build-essential autoconf automake libtool flex bison scons

Your gcc should be at least 4.7.+

Cheers
Tom

62

There’s just too much hassle - in many, many areas; a project team has to dedicate at least one full-time staff to testing and troubleshooting upgrading the project to 1.2 - and God knows how much time it will take him.
Whereas updates should bring benefits instead of drawbacks, not to mention be seamless.

1 Like
63

@tomfreudenberg: The problems I’m having with fourseven:scss are:

  1. Referencing files in the /.meteor folder isn’t working any more. I’m using mquandalle:bower to download SASS files for libraries like Bootstrap and the Material Design Icons. Bower stories all files under /.meteor, in a special build folder. Including these files worked as a charm in 1.1, but fails completely in 1.2. According to responses to my Github issues, there is no workaround for this other than manually copying the downloaded files to another location - which breaks automatic updates.

  2. Referencing relative files does not work any more, so each and every SCSS file has to be referenced using an absolute path. This is a huge drawback compared to standard SASS behaviour. Maybe this will be solved soon, but at the moment it would force me to re-work my whole SCSS file structure.

64

Just another failed upgrade story:

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. :-/

65

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.

66

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 :- )

67

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.

68

Thanks Tom! That’s a great tip. We’re just using the official binaries at the moment but will bear that approach in mind for the future.

69

Hi Mark @mrw34

There isn’t a big difference in the source by now as you may see

but the compiling does enable PORTABLE

and so it will not conflict with any “global” elements as if you use system binaries.

Cheers
Tom