As with most x.y.1 releases, Meteor 1.4.1 contains a number of incremental changes intended to polish and patch the recent 1.4 release. With that said, this release also contains some exciting new features that we will highlight below.
Any idea when we might see code-splitting? Initial page load has become disastrous in my app and weāre going to have to migrate off of Meteor if we donāt get code-splitting in the next few months.
So on MacPro OS X 10.11.6 it downloads and then seems to hang installing. Is there a way to enable debugging to know what is going on? This spinner is what I am staring at for the last 30 minutes
I tried to install 1.4 and gave up finally three hours later.
I could not install the Scss, sass pckagrs required for the meteoric package my app uses.
Did anyone manage to get this running?
The blog entry says to re-install when it takes to long. Unfortunately re-installing removes .meteor and all the previously downloaded and installed versions and packages. Major PITA.
For my medium size app I decided to go the clean way for upgrading:
( running on a Ubuntu 15.10 Desktop )
Filesizes before upgrade:
~/.meteor folder : 8.4 GB ( yep, massive)
~/Desktop/myproject/.meteor/local/bundler-cache : 212MB ( I had it cleaned out a few days earlier. But keep an eye one this one, it can become very large also. )
The whole proces of downloading, installing and upgrading was about 3 minutes.
BTW: My build-times:
changing a client-side file: about 3secs to rendered results
changing a server-side file: about 3secs to server restart
changing a method( which requires both server and client rebuild: about 6secs to rendered results
I donāt know, maybe Iām just lucky, but I have similar results on several apps ( small, medium and large-size). Even on my old laptop I get results after about 10-12 secs, and that one is running a virtual Ubuntu 16.04 on a Win7 Virtualbox host.
yes, jamgold, i had that spinner for 4 - 5 long daaaaayz ! finally just completed the update. I have not updated in a long time, so maybe that was part of the issue (?)
There have been a number of issues on github related to this issue, in a lot of cases it had to do with the CDN. Adding an entry into your hosts file for warehouse.meteor.com solved it for a lot of people.
Steps below:
host warehouse.meteor.com
edit /etc/hosts and put the IP from no. 1
restart networking after no. 2
After 1.4.1 Iād assume it would be safe to remove the hosts entry again.
Thanks for this update. Now I am back on the train, no more ādownloading toolingāā¦I had to create a new meteor app and just copy my old files to the new directory and run āmeteor addā on all packages I used and now my app works perfectly as before. So far things really seem to work faster. Looking forward to future updates.
BTW I am on Windows 10 recently updated to build 14393.0. Also installed on Fedora 24, so far it works well too
@benjamn re: the build tool, what about keeping the current build tool as a āstarterā build tool for smaller apps, but make it very easy to switch to Webpack when build times become too slow?
The reason I ask is because from what I can gather, improving the build tool is far from trivial. So I just wonder if we couldnāt find a āshortcutā instead?
For build performance, I saw someone mention that disabling transpiling javascript for development would really speed things up. I think itās a good ideA.