Announcing Meteor 1.7

[orloff]

If request come from modern browser, legacy bundle does not load to client at all?

[antoninadert]

MDG has got some money, they should spend some on a proper marketing team.

But I personally feel alright with current community size. Big communities tend to be hard follow and go in all directions. MDG is currently focused and lucid. That’s what we need (maybe not what you want)

But for me it is a sign of longevity and maturity what we have right now.

[abernix]

@orloff Correct! A big part of the “win” that Meteor 1.7 provides is that the client JavaScript bundle size is reduced and optimized for modern browsers. That means not shipping the legacy bundle (and saving those precious bytes!) to modern browsers that can natively handle newer JavaScript/ECMAScript features.

[seba]

MDG has got some money, they should spend some on a proper marketing team.

Then again, spreading the word is one of the easiest and most accessible ways for the community to contribute back.

[jkuester]

This is more than awesome

But there is one thing that makes me wonder a bit related to packages:

Package.onUse(api => {
  api.mainModule("client.js", "client");
  api.mainModule("server.js", "server");
});

This code still works in Meteor 1.7, though it means the client.js module will be loaded by both the modern and the legacy bundle.

So do I get it right, that this benefit will be reduced by unmaintained packages? If so, we need to push package owners more than ever to update and maintain their packages. This is a serious issue and discussed in this forum as well right now.

[benjamn]

Unmaintained packages will continue to work as they always did, so there’s no regression in Meteor 1.7.

In fact, because Meteor package and application code gets recompiled by whatever version of the ecmascript package you’re using, existing packages will immediately benefit from modern compilation without having to publish any new versions. This is fundamentally different from how npm packages work, since npm package authors are responsible for compiling their code before they publish it to npm.

If you’re writing a Meteor package, the only reason to use the modern/legacy system explicitly is if you want to take a completely different strategy for implementing some part of your package in modern browsers. Most other benefits of the modern/legacy system are completely automatic.

So while I agree that unmaintained Meteor packages are a problem, I do not see the modern/legacy system as a wedge that makes them any more problematic than before.

[benjamn]

Here’s another historical precedent for modern/legacy bundling that I’ve been seeing mentioned around the web:

Ben Newman (benjamn)

While I think this strategy is clever (and sometimes the only option), I explain why Meteor 1.7 does not work this way in a series of replies to the original tweet.

If what I’m saying in this thread makes sense, please consider retweeting it!

[angle]

I’m having the same trouble I had upon upgrading to 1.6, which I was never able to solve - it throws an error about not being able to find underscore, despite having added underscore to the project. I found a stackexchange which seems kinda relevant but I’m not actually sure how to solve my problems based on it: https://stackoverflow.com/questions/25254848/error-cannot-find-module-underscore-thrown-from-boot-js-in-meteor-bundle

I too have node_modules in my gitignore, but I’m not transferring files through git, just backing them up? But Maybe I’m missing an npm underscore or something. Any advice on how to solve this? Should I try like “meteor npm install underscore” or something like that?

Edit: Tried “meteor npm install underscore” and it didn’t change anything.

[benjamn]

Try meteor add underscore? Meteor packages and npm packages are different animals. The meteor npm install underscore approach could work too, but then you have to import _ from "underscore" explicitly when you want to use it, which some folks prefer!

[angle]

I tried meteor add underscore before, and it didn’t work. More recently, the update added it for and it still didn’t work. I tried it just now, and it said “underscore without a version constraint has already been added.”

Edit: So far all the stackexchange answers seem to say “Uninstall and reinstall meteor”, so that’s what I’m gonna try next: https://stackoverflow.com/questions/18678924/error-cannot-find-module-underscore-thrown-in-console-for-all-meteor-commands

Edit: Lol, no, still has the same problem. Even after all that.

[angle]

Alright, I think it’s actually a problem in underscore. Specifically, the part where it goes:

/* Exports */ Package._define("underscore", { _: _ });

Is throwing an error, “Reference Error: Package is not defined.”

Not sure what causes this?

[skini26]

I read the post and saw the complete presentation here but couldn’t find anything related to backend features. What’s new on that side ?

[hwillson]

You can see the full changelog here.

[skini26]

Thanks. So there’s nothing new on that side, was hoping for something related to the new mongo change detection api or some appollo integration.

[a.com]

More so than ever before, Meteor is now ahead of the game, and other frameworks will have to catch up.

Damn. Shots fired.

When they tell you “sure, but that won’t work in IE10,” smile and suggest they have a seat, because you have some great news for them.

#GetTheStrap

[a.com]

was hoping for something related to the new mongo change detection api or some appollo integration.

Mongo would be cool but apollo integration isn’t too bad as of now. Source maps in production for errors would be good. Jest can also be a headache with meteor, but not sure what MDG can do there.

[merlinpatt]

Is there a way to see this in action?

I don’t mean seeing the different sizes in the bundle-visualizer.

But what do you suggest so I can see that this in fact working with my application?

[waldgeist]

I tried to upgrade my 1.6 app to 1.7.1 today. Quite a bad developer experience. First, I ran into

Issue: Updating from 1.6.1.1 to 1.7-rc.2 leads to Mongo exit code 62

then into

Issue: [1.6.1] TypeError: Path must be a string. Received undefined

I was really hoping that these update horrors had been resolved. Downgrading now…

[benjamn]

That’s the tone of someone who believes the only way to get help is to overstate the “horrors” of their case. I’m sorry that’s your first instinct, but perhaps we can start over in a github issue thread where we can diagnose the problems you encountered, rather than using this announcement thread?

[arggh]

I was really hoping that these update horrors had been resolved.

I feel like I have to defend Meteor on this one. We’ve had an app in production for over 2 years, currently running Meteor 1.6.1. The same code we wrote two years ago works today. It’s been a pretty smooth ride to here too Sure, I’ve posted issues on Github and even made PR once or twice, but that’s how it works. I think there still isn’t a platform on this planet that would have enabled us to get to this point as fast and efficiently as we have with Meteor.

Nowadays our biggest concerns are some of the community created packages whose authors have moved on and lost interest in keeping them up to date, latest of them being the vsivsi:job-collection. This is one of the pitfalls of the otherwise very powerful Meteor-specific package system. Luckily the community has been pretty good at continuing the work of others!