Coming soon: Meteor 1.4

sashko · June 21, 2016, 5:49pm

That’s interesting, I must have misunderstood it. I bet @benjamn will know more, but my understanding was that Meteor supports all of the syntax.

XTA · June 21, 2016, 6:08pm

Isn’t it all about how you define & export your class?

For example

export default class VideoModalItem extends React.Component { }

Import:

import MyVideoItem from './VideoModalItem';

and

export class PostingNew extends React.Component { }

Import:

import {PostingNew} from './posting_new'

rlivingston · June 21, 2016, 7:41pm

I’d guess they are using the babel transform-export-extensions plugin somewhere. The exact syntax you showed appears to be a stage 1 proposal for ecmascript by Lee Byron, not yet part of the standard. Other proposals for those interested are here.

daveeel · June 22, 2016, 3:57am

I’m using exactly the export default syntax for exporting.
And I’m looking for export XXX from ... instead of import XXX from ...
I’ve been experiencing different combinations for a while to try to simplify codes.
Using export XXX from ... raises Unexpected Token syntax error right after export

tomfreudenberg · June 22, 2016, 9:39am

@sashko @zoltan

Will you use or update your fork from mongo source like you did for 2.6.7 at https://github.com/meteor/mongo

I ask to prepare the new parts for Meteor universal fork on ARM devices.

This time I had to add ARM support for v8 into that extended fork at https://github.com/4commerce-technologies-AG/mongo

Would be nice to get an info so that we can start the port to mongo 3.2

Thanks
Tom

tomfreudenberg · June 22, 2016, 6:48pm

Today I had a short conversation with Sing-Li from Rocket.Chat about using ARMv8 (64bit) boards. I am curious if we can make it there too with node v4 and mongo 3.2. That would enable those new sets of ARMv8 servers.

viclei · June 23, 2016, 4:24pm

Awesome news MDG! Way to go team - super excited for Mongo 3.2.

tomfreudenberg · June 25, 2016, 11:47am

Hi

@sashko @benjamn

I started with porting of the meteor branch release-1.4 to the ARM architecture at https://github.com/4commerce-technologies-AG/meteor/tree/release-1.4-universal-beta

You may follow the track at https://github.com/4commerce-technologies-AG/meteor/issues/42

I also add the new ARM64 (armv8l, aarch64, arm64) support and that is what currently blocks: see my issue at the babel tracker: https://phabricator.babeljs.io/T7457

Maybe someone has an idea on that.

Cheers
Tom

tomfreudenberg · June 27, 2016, 3:16am

At the end of this weekend, we had success and meteor-1.4-beta is already running on ARM and the brand new ARM64 architecture. Looking forward to this new server hardware …

@benjamn: Please be aware of these two bugfixes for nodejs and node-fibers. It would be great, if meteor-1.4 will beget upgraded to their latest stable releases when our PRs are merged.

NodeJS 4.4.6 : ARM64 bug https://github.com/nodejs/node/issues/7417
Node-Fibers 1.0.13 : ARM64 patch https://github.com/laverdet/node-fibers/pull/293

Cheers
Tom

tomfreudenberg · June 27, 2016, 11:49am

@zoltan @benjamn @sashko

Meteor-1.4 beta is now ready for running on ARM v7 and v8 (aarch64) architectures.

I finally have also built and included in the dev_bundle.tgz the node v.4.4.6-patched (will be replaced with next node v4 stable), the node-fibers v1.0.13-patched (will be replaced when patch comes to stable) and finally also a mongo r3.2.6 from their github.

As a test I run the simple-meteor-react example, with no issues

Question might be if we should invest additional effort into ARMv6 architecture (Raspi 1/A) - I will check via vote on Twitter.

tomfreudenberg · July 1, 2016, 8:49am

Latest Meteor 1.4 (beta.6 tag) is ready to run on ARMv7 and ARMv8. Performance on linaro ARM cluster is very well. Looking forward to some hosters like skaleway but with ARMv8 boards.

For someone interested on tests, I will leave a dev_bundle for aarch64 (ARMv8) on bintray. The build scripts are currently not 100% finished. Testing for the right compiler directives.

Cheers
Tom

UPDATE: If you like to try that version please use

git clone --depth 1 --branch release-1.4-universal-beta https://github.com/4commerce-technologies-AG/meteor.git

for checkout

balupton · July 1, 2016, 1:28pm

See GitHub - bevry-archive/esnextguardian: Superseded by the editions package: https://editions.bevry.me and its successor GitHub - bevry/editions: 📦 The best way to produce and consume the JavaScript packages you care about.

XTA · July 14, 2016, 8:08am

Any idea when 1.4 will be officially released?

jononomo · July 14, 2016, 3:55pm

Also, will 1.4 solve the issue with super-long build times? This is the one thing that absolutely drives me up the wall the most and just kills my productivity.

hwillson · July 14, 2016, 4:38pm

No official release date has been mentioned by MDG, but since the beta is now at 1.4-beta.14, I’m guessing we’ll see a release candidate very soon.

The main focus of 1.4 is:

Upgrade to Node 4
Upgrade to Mongo 3.2 (using WiredTiger 3.2 by default)

Tackling rebuild times hasn’t been discussed by MDG yet, but the issue is being tracked here (add your +1’s accordingly):

github.com/meteor/meteor

Meteor build time/refresh time after file save is VERY slow

opened 07:31PM - 27 Apr 15 UTC

closed 07:39PM - 11 Nov 16 UTC

cdcv

Project:Isobuild:Performance

**_4 Upvotes**_ I have reasonably large app that I'm working on. When I make any… change to the code and press 'save', the time to build the app and refresh the browser is very long, and also highly variable. It is typically 30-60s. A colleague is working on the same app, and is using a similar machine (both are 1-2 year old high-end MacBook Pro), and in his environment the build time is typically <5s. When I make changes to a small demo project, the refresh time is <2-3s. I have tried a bunch of things, including reinstalling meteor, but to no avail. This is bringing development to its knees. What can I do? Thank you for your help?

Spyridon · July 14, 2016, 5:25pm

I think this is an actual BUG and not an issue of 1.3, let me explain…

Upon the first time I upgraded to 1.3, after upgrade I had ridiculously long build times. I found this weird as build times were supposed to have DROPPED. But mine were higher than ever before…

I had to revert. Upon reverting everything was back to normal.

Then I decided to give the upgrade a try again - on my second attempt, everything ran GREAT. Reload time was no longer an issue.

Then one of the incremental patches came out, 1.3.2 i think? Upon doing that upgrade, the SAME ISSUE happened. I reverted again, did the upgrade again, problem fixed.

I gave somoene else this advice once before and it worked for them as well.

It seems the updater (at least the windows one) has some errors that are completely screwing the build time.

tomfreudenberg · July 14, 2016, 5:35pm

Hi, have you ever tried to check what happens if doing a complete fresh meteor 1.3.x installation? Would be interesting if this run as quick or if the magic is in the “update - revert - update” process

Ben · July 14, 2016, 6:24pm

huh? as far as I could tell by earlier threads, I thought people were working hard on this. Well guess not Just adding my 0,02, having 30s rebuilds in event the smallest possible app (ssd even) is kind of unworkable. Especially since it’s on every single small html tweak you do.

hwillson · July 14, 2016, 6:55pm

Well, there has been a lot of discussion about it, but I just meant there hasn’t been any official statements (or schedule) from MDG about how they’re planning on addressing this issue. Each new release adds incremental performance improvements, but the larger issue definitely still needs to be addressed.

Given that issue 4284 has 155 comments and growing, you’re not alone!

Spyridon · July 14, 2016, 8:09pm

That should not be the case unless you have the bug I mentioned above. if 1.3 is working as intended it should be pretty fast (mine is a very large project and takes only a couple seconds)