Their is no HMR (hot module replacement) to work with the Blaze state. I would presonally love to get HMR inside Meteor isobuild and forget about webpack. Seriously.
Anybody can get me in contact with the guy that built isobuild? (I’m guessing it’s @slava by the Git commits). I would love to help Meteor add HMR inside the meteor build.
That would allow anyone using Blaze, React or Angular to have hot-reload with no page refresh. 10x faster (like with webpack)
Browserify also has HMR. It would be a huge gain to the Meteor stack to have a faster hot reload (it’s like real-time fast). And we can keep our holy build system ;).
That would be amazing. Anyone can help me get in touch?
@benoitt So I just started checking out Webpack this week and its pretty amazingQ HMR is so damn fast. You wouldn’t think its that important, but its so nice to have. I also really like how you can require assets like css, images, fonts, etc from js / scss and it will all get included in the distribution bundle. Inline React SVG is sweet as well. I’m totally sold on webpack.
I think Meteor needs to think about how they’re doing things. While package.js with isobuild is awesome, its not able to leverage the rest of the development community. What if I want an inline svg loader for react? Well have fun getting that working with Meteor. And why do I have to organize my files a certain way? Or using packages, why do I have to manually add every damn file in package.js explicity setting the load order. LAME! Webpack solves all of these problems.
I really think Meteor needs to move towards something more NPM and Webpack compatilble. They’re inventing the wheel twice! Why would you implement HMR in Meteor when Meteor doesnt even support modules yet? Theres no reason. It would be a waste of time. Leave antiquated technology behind – thats my thinking at least.
The only thing that hasnt been worked out nicely with Webpack is isomorphic builds and packages. Maybe someone else has figured that out – I’m not sure. But my prediction is that soon enough, someone is going to build something comparable to Meteor using Webpack and React. You’ll be able to deploy to Android, iOS, Web, Electron, Cordova, etc. Thats the future. No reason to fight it!
When you change something in the meteor folder, it will restart the Meteor server. If you run webpack on Meteor, it will recompile the whole webpack application at the same time. This means if rebuilding webpack takes 15 secs, it will add an additional 15 secs to your Meteor restart EVERY time you change a file. Quite anoying.
By running wepback on a separate server, webpack is not affected. I’m sure you would prefer that
Oh yea, i did notice that problem, awesome! Thank you so much. Also, node process went down to .1% after using separate dev-sever. (was more than 46% + ).
Another question about the hot reload errors, i notice you commented out the redbox stuff in config, so how do you deal with errors in react now? I think even though the line numbers are not correct at least i immediately know where the error is, but having it turned off makes it not obvious that theres errors unless i open up console in browser.
Don’t you develop with your Chrome console or Firebug open? You will immediately see the error. If you don’t care about line numbers (personally I think stack trace is enough), you can uncomment it. It is commented instead of removed so it is easy to be reactivated.
I do but it is usually not in the same window(my screen is not that big), So i have to switch over to see the erros. But gotcha i will just leave the rebox on.
I just added AminApp to the kickstart project. It is an example of code splitting. It will only load the admin stuff on the client if you visit /admin.
I get errors when trying to ‘meteor deploy’ the simple kickstart version:
Errors prevented deploying:
While linking the program:
error: npm-container is not compatible with architecture ‘os.linux.x86_64’
I’m guessing this means using webpack isn’t compatible with using isobuild to deploy?
Nop, not at all. It has nothing to do with webpack. It is a technicality with NPM modules that regular Meteor project also have. I’m working on a fix so that you can have a webpack.packages.json file that will not bundle the NPM modules with your webpack project (it is bundled with it anyway, you only need it on the server if you use Meteor.npmRequire).
You can follow this bug issue if you wan tot learn more and know when it’s fixed (probably soon).
