This is a bit off-topic for this thread, but Meteor 1.3 will indeed support Cordova iOS 4.0.
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.
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
shared
resolves 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
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.
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?
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.
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!
Video: Using Webpack with Meteor
Meteor + Webpack from the Ground Up
Meteor + Webpack + React Router: A Basic Template with Code Splitting
Yes you can do code splitting with Webpack. Essentially, the client only load the javascript of the section when he access it.
You can check the kickstart-hugeapp example where there is an admin page that will not be loaded to the client unless you access /admin.
I took the time to look on how we can implement Hot Module Replacement within the Meteor build and my head is hurting . I donāt think Meteor will ever see fast hot-reload without using webpack.
What if we made webpack so easy to use with Meteor it would be stupid not to use it? What if all you needed was to add a few packages and not even a simple configuration file to write? As an example, if you want to use JSX, you just add the webpack:jsx-loader
package. You want TypeScript? You add webpack:ts-loader
. The configuration will write itself.
It might give enough flexibility to 95% of the projects and those that really need to configure the webpack.conf.js file, they still can do it.
You bought me, when can I start using it?