@gaurav7 You could use @benoitt’s solution and get that feature for free 
1 Like
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.
7 Likes
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.
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.
2 Likes
This is a bit off-topic for this thread, but Meteor 1.3 will indeed support Cordova iOS 4.0.
8 Likes
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.
20 Likes
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 likerequire('moment')the resolver will first
try to find it innode_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
sharedresolves the same way with webpack
modulesDirectories. This way you don’t have to
require('../../../../../../../../../../shared/Avatar')you can simply
dorequire('shared/Avatar')no matter where you are.
This! Reload times are getting really out of hand on our project, up to one minute on decent machines (i5, ssd, 8gb ram)
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 
Thanks thats a relief ,!
I think the time it takes to learn webpack is truly rewarding
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 
1 Like
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.
4 Likes
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.
A bit off topic, but 2 questions:
-
I really like the cross-package imports Meteor has for css preprocessors like less and sass. Is there something similar for webpack?
-
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…
@benoitt et al., Webpack sounds interesting. I have a situation in which I would like to push down to the client only the (template/view/code) it needs, as it needs it.
For example, say they’re going through a wizard. I know there are 10 screens associated with this wizard. As the client starts the wizard, I push to the client the first 2 or so screens, and as they progress I send them more.
I’d like to make the connections between (templates/code) with tags if possible.
Having the capability for the client to request On Demand Resources is great. But I’d also like to use this to restrict what the client as access to. For example if a client has not purchased a feature, and it’s not enabled and they don’t see or have access to the screens, why should they actually get the screen pushed down to the client? The client should only get what it needs. Right now, it’s complicated to restrict screens, and through packaging I don’t think it can be dynamic. For example, what if the client actually pays for this added feature, dynamically sending the client the feature screens because they’ve paid would be amazing.
Maybe something analogous to Apple’s App Thinning (On-Demand Resources)?
Is this something Webpack will allow me to do?
2 Likes
This is exactly the reason we need this, perfectly summarized by the author of the Webpack integration module! If we can get the Meteor build system to have hot-reloading and be comparably-fast as Webpack, then I think we’ll be onto a winner.
2 Likes
Yes, you can do modular code loading with Webpack.
Within Meteor? How? Is there a How-to guid on this?
If this turns out to be the case, then yes, please MDG standardize around Webpack!