Meteor 1.3

[tonyxiao]

Does this repo support meteor 1.3?

[rclai]

It doesn't work very well, I tried it just now.

[ramsaylanier]

Would you really need 1.3 with this setup anyway though?

[tonyxiao]

You may not need 1.3 for the new features it provides, but meteor is moving to 1.3 regardless and we probably wouldn't want to be stuck with an old version right?

[ramsaylanier]

I'd imagine it would still work though as 1.3 modules are optional.

[rkstar]

@rclai what doesn't work very well? what problems did you hit?

[rclai]

Off the top of my head:

I was using master branch, Template.loginButtons was not found during runtime, the initial App component wasn't able to be mounted because the root html element wasn't in the DOM for some reason even though it's there in the meteor.html file. So it seems like Blaze wasn't working quite right.

Every time you made a client component change, it would restart the meteor server so the hot reloading was slow. I think that might be related to one of the 1.3 issues.

[jedwards1211]

The Template.loginButtons issue is fixed.
As a side note, I've actually been using Meteor 1.0.5 for a long time because of the problem with 1.2 hanging/taking forever to process large JS bundles. But yeah, eventually I should look into working with 1.3...

[rclai]

No rush.

[rclai]

Now that a new beta is out where they've resolved a bunch of stuff, it's time to try it out again.

[Mokto]

1.3 is out 👍

I would be happy to help migrating this plugin to 1.3.
Remove unnecessary code, etc...

[jedwards1211]

I don't think there's much to remove besides the custom-built core-js (and we should make sure the one from Meteor works for the Webpacked code as well, including the Number constructor issue -- i.e. testing Mongo.Collection.find({...}, {limit: 10}))

[jedwards1211]

Also, we need to verify that we can prevent the large bundle issue (supposedly naming the bundles *.es5.js keeps it from choking on large bundles even when not using the ecmascript package).

[BodhiHu]

Why not simply in a webpack project use Asteroid(https://github.com/mondora/asteroid) to communicate with a meteor server ?
In that case the codes would be clean, not so complicated.

I've been trying to get my webpack-react app working with meteor, but the two kinds packaging systems tangled together, just felt not so right. After two days, I decided to simply go with the Asteroid approach.

Unless Meteor officially supports webpack, though it would be best if meteor could let us use its packages through npm.

Anyway, best wishes : )

[jedwards1211]

@ChrisOHu Yes, asteroid would be cool, but I think its API is too different from the Meteor API to use for a general-purpose skeleton project. At least not this one. For instance, you don't get to use Minimongo with it, so you have to do something else.

Feel free to set up your own skeleton project though!

[jedwards1211]

@ChrisOHu also, I've seen some Meteor devs say on the forums that they plan to transform Meteor into a bunch of npm modules.

[BodhiHu]

Hi @jedwards1211 thanks for the info : )

[Mokto]

See #140

[jedwards1211]

Hi everyone, I now have the solution for using Meteor 1.4!

It's a new app skeleton that's way slicker than this: jedwards1211/crater

It sidesteps Isobuild for everything but installing and building meteor packages. All of your own code runs via babel-register (server) or Webpack (client). It starts faster than running via Meteor 😸