What's blocking you from updating to Meteor 1.2?

core
44

Hmm, I guess those who have trouble rolling back must not have been using source code control or else had problems in spite of using source code control.

45

The first error we got was

=> Errors while initializing project:         
                                              
While building package npm-container:
error: No plugin known to handle file '../../packages.json'. If you want this
file to be a static asset, use addAssets instead of addFiles; eg,
api.addAssets('../../packages.json', 'client').

The packages.json, in our project root, lists a single NPM package that our project uses.

We resolved this issue by following the instructions from meteorhacks:npm:

rm -rf packages/npm-container
meteor remove npm-container
meteor update meteorhacks:npm
meteor
1 Like
46

We also get a LESS error during the build process:

=> Errors prevented startup:                  
   
   While processing files with less (for target web.browser):
   client/style/global.less:3: Unknown import:
   /packages/bootstrap/bootstrap.import.less
   
   While processing files with less (for target web.cordova):
   client/style/global.less:3: Unknown import:
   /packages/bootstrap/bootstrap.import.less
47

I am using 1.2, but it has been a real pain trying to get MUP to work. I went to MUPX and it works, but Iā€™ve now lost the ability to do multiple VHOSTS in Nginx.

So it has been a kind of cascading effect. I upgraded, then SASS stopped working, fixed that. MUP stopped working, fixed that, Nginx stopped working and that is where Iā€™m at now. I like some of the improvements, like ES 2015, but Iā€™m wishing I could get back all this lost time of fighting with Meteor and all the changes.

UPDATE:

Mup seems to be working now. Havenā€™t looked to see if SASS is working, but I can just pin that to an older version until I hear that it is all working. Should be moving to 1.2 next week on my main production app.

1 Like
48

If I just want to give 1.2 a quick spin, can I just cut a branch of my project and do the update in that branch and then revert back if I need to?

Iā€™m just not entirely clear what will be updated locally if I do the 1.2 update and whether this will force me to move forward.

49

Yes. Stuff in the .meteor folder is updated and can be reverted easily.

1 Like
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.