Why is the Meteor.install(1.3) api better than webpack in meteor?

[gaurav7]

@fvg

This means you can safely write if (Meteor.isServer) {} or just if (!Meteor.isServer) { return; } and webpack will remove the "dead code on the client, once configured properly.

Hey @fvg, I want to do exactly this in a current project. Could you elaborate on how to configure webpack for this? Or point to relevant resources? Thanks!

[namike]

@kzvaigzne strongly agree with you. We just need HMR like feature and we will have a happy Xmas ( My teammate just push “change in one second” in his Xmas wish list lol )

[manuel]

@kzvaigzne

I care much less about import/export/require than I do about the INSANE difference in reload(/refresh) speed between “Meteor native” and “Webpack” solutions.

I couldn’t agree more.

I was watching a presentation of DoneJS and all I could think of was “Meteor should have this by now”: hot reload, SSR, and progressive loading. It would also be nice to have a good story for routing and testing too, not just “the community will provide”.

[fabiodr]

+1 for fast recompile/reload. It is so important… and takes away so much productivity. There are many issues in github about it going on for months, for some people it even got worst with 1.2, with more than 40 SECONDS to rebuild with a not so fast PC without SSD.

It should be a high priority fix and released as a minor version as soon as possible.

I can handle other limitations of Meteor and work with its strenghts, but that one…

[aislan]

+1 for faster reload times. It is a MUST HAVE now.

[fvg]

@gaurav7 You could use @benoitt’s solution and get that feature for free

[mquandalle]

@kzvaigzne

I’ll be completely honest, at the moment atleast, I care much less about import/export/require than I do about the INSANE difference in reload(/refresh) speed between “Meteor native” and “Webpack” solutions.

I would also like to know if MDG plan to address React components hot reload in Meteor 1.3.

If not (which could be reasonably argued as well) I’ll probably use webpack:webpack in Wekan — at least temporary while migrating from Blaze to React assuming that the time spent configuring Webpack would be recovered in the shorter iteration process during the UI rewrite.

[gaurav7]

Thanks @fvg! Unfortunately I can’t switch to it right away. I’m using a fairly customized version of https://github.com/jedwards1211/meteor-webpack-react

But that’s a useful pointer, gonna try something in those lines.

[markoshust]

Will 1.3 support the new Cordova release? http://cordova.apache.org/announcements/2015/12/08/cordova-ios-4.0.0.html

+1 for hot reload also. it’s a need.

[martijnwalraven]

This is a bit off-topic for this thread, but Meteor 1.3 will indeed support Cordova iOS 4.0.

[benoitt]

Hey everyone,

I think it is a fair question to ask ourself do we really need Webpack or should we go with pure Meteor? Why should we use such a complex tool while we have something great that is simple to use.

To be honest, when I wrote the Webpack plugin for Meteor it was out of my own need to use it on a major project. It wouldn’t be as near as useful if it was a small project and as someone developing 100% React with Meteor, it was REALLY helpful for fast hot reloading, building assets (most people here don’t know this but it rocks) and code splitting.

The good news here is most people only care about fast hot reloading. And as a matter of fact I know it can be as fast with Meteor 1.3 because the hot-reloading of React is not built on top of Webpack but on top of Babel (hey! meteor use this we’re lucky ). It has already been done for Browserify, why not Meteor build?

If we add HMR to Meteor, we will be able to do exactly the same fast hot reloading than Webpack. Then, you wouldn’t need to use the complex Webpack config files unless you have a major project that needs a complex configuration.

I think this is the future of Meteor and I’m hoping the community will be happy to go there. I wish I had more time to contribute to this.

[fvg]

Hey @benjamn, I think I’ll use this structure for my react app once 1.3 is out. The question is, if Meteor.install will also allow to have imports like this:

Shared module resolution

The way modules in CommonJS are resolved is pretty straightforward in
practice: its all relative from the current file.

There is one piece of “magic” in the way modules resolve. When you do a
non-relative require like require('moment') the resolver will first
try to find it in node_modules/moment. If its not there, it will look
in ../node_modules/moment, and on up the tree until it finds it.

We’ve made it so that shared resolves the same way with webpack
modulesDirectories. This way you don’t have to
require('../../../../../../../../../../shared/Avatar') you can simply
do require('shared/Avatar') no matter where you are.

[seba]

@kzvaigzne

I care much less about import/export/require than I do about the INSANE difference in reload(/refresh) speed between “Meteor native” and “Webpack” solutions.

This! Reload times are getting really out of hand on our project, up to one minute on decent machines (i5, ssd, 8gb ram)

[harisvsulaiman]

Does this mean you wont be supporting the webpack plugin anymore.

[benoitt]

@harisvsulaiman

Does this mean you wont be supporting the webpack plugin anymore.

NO! Absolutely not. I will continue to use Webpack and would suggest anyone with a large project to do so.

But Webpack is not so easy to use and I think non-webpack users deserve hot-reload without page refresh

[harisvsulaiman]

Thanks thats a relief ,!
I think the time it takes to learn webpack is truly rewarding

[fabiodr]

Webpack can’t help Meteor with server-side code, or can it?

All this build delay have an unmeasurable impact on development process iteration…

Looking at compilation profile output, seems it check packages versions, plugins, reminify all css (even if it is not modified) and a lot of other stuff that is not related to the modification

[SkinnyGeek1010]

Webpack can’t help Meteor with server-side code, or can it?

It can! I’ve been using it in the jedwards meteor-webpack version and it’s been working well. It does however, add more config code (almost 2x lol):
https://github.com/jedwards1211/meteor-webpack-react/blob/master/app/main_server.js

All this build delay have an unmeasurable impact on development process iteration…

I agree! I was about to leave Meteor until webpack saved me. I was creeping into 18-20 sec reloads on an i7 quad core. Now it’s like 1.4-.1.7 tops.

[sparaker]

I would +1 on the effort to improve reload times and build times in general, because i have seen meteor kind of slow up on a system with an SSD and a good enough hardware as soon as the project becomes slightly big, and i am not talking about big in the BIG sense really. So this is definitely something you guys should work onto, if meteor starts killing productivity which it is currently, than the value it adds isn’t so much to keep using it and this is something that needs to be addressed fast.

[seba]

A bit off topic, but 2 questions:

1. I really like the cross-package imports Meteor has for css preprocessors like less and sass. Is there something similar for webpack?

2. Is there some kind of migration guide on how to transform existing meteor apps to webpack? I can’t live with Meteor rebuild times anymore…