While the Meteor community was hacking projects this weekend, I was also hacking but the Meteor build system . You can now seamlessly integrate Webpack within your Meteor application.
Why should you do this?
Hot-reload with React (probably doable with others): The amazingly fast hot-reload with no page refresh. This is a killer feature. Works with Cordova!
ES6 modules: this will be introduced in Meteor in the future but with Webpack, you can be in the future!
Bundle your assets for you when you require them
Code splitting: you can actually make people only load a part of your application and dynamiclly load the rest when they need it. This is actually great for admins and stuff you donāt want everyone to download no matter where they are.
Support Cordova!
You can configure your Webpack config on the server and on the client by using exactly the same syntax as anyone using Webpack. Obviously, it has been simplified because it needs to be built inside Meteor so it will override a few configs.
Well done. Iām impressed you were able to able to do this entirely through a package, but it makes sense. Looks like the Meteor build system is more flexible than I thought. If only meteor had formal documentation for it!
Hereās an idea to take it a step further. Would it be possible to create an api so so we can add webpack.client.js and webpack.server.js to individual packages like coffeescript or jsx to configure webpack just as we do with any other package? This would ease some the webpack learning curve. I think MDG would be all behind that.
Thanks, it would be amazing considering I am not registred haha. I donāt think It took me 4 days morning to night to get this right.
Iām not sure I understand your idea. Do you mean instead of configuring JSX inside Webpack you could add wepback:jsx and it would include JSX inside Webpack automaticlly? I think itās a good idea. I want to keep the flexibility of editing your own config file because everyone want a different build process. I think itās worth considering, at least for beginners.
Not yet but it is on itās way. I donāt see any reason why I would not. It makes the deployment and the build so much easier to deal with.
I was really focused on optimizing your Webpack config out-of-the-box so it made sense
My kickstart projects are missing unit tests and integration tests. Then I will be satisfied
I can not test it right now, but do source maps work = important for debugging? I just skimmed the repo and that really looks like a clean awesome implementation.
I havenāt tested it with Windows yet but Iāll be doing this today.
Thatās weird. You should try to delete your folder /C/Users/username/AppData/Local/.meteor/packages/reactrouter_react-router and build again. The symbolic link for node_modules might be problematic too. Iāll be testing Windows today.
YES I did worked a great deal to make sure the source map Webpack is generating is sent to Meteor build system. You will have a clean call stack / line numbers!
I just got home checking it out right now. Seems to work flawlessly. Your webpack:webpack implementation is incredible close to what I started -> kicking out the meteor build process instead of servering files back and forth from a shadow directory.
I am looking for a flawless TypeScript integration with modules to better server enterprise application structures without pre-compilation. Wondering now if meteor-webpack already plays along with the TypeScript loader https://github.com/TypeStrong/ts-loader
Probably most people will prefer this way of doing things, though Iām wary of having the system automatically decide what to inject into my Webpack config ā I want full control over that. Iām more into flexibility than ease of use. For instance I would prefer to get to use 0.0.0.0 as the host instead of localhost, so that I can debug on mobile devices over LAN.
function prepareConfig(target, webpackConfig, usingDevServer) {
if (usingDevServer) {
webpackConfig.entry = ['webpack-hot-middleware/client?path=http://localhost:' + WEBPACK_PORT + '/__webpack_hmr', webpackConfig.entry];
}
There is already a perfect, standardized location for dev server settings in the Webpack config files ā I would recommend just reading the host and port from config.devServer.host and config.devServer.port instead of e.g. a WEBPACK_PORT environment variable.
The commons chunk thing is convenient if it fits oneās use case, but sometimes people want multiple commons chunks too.
When I had tried to write something like this, if I killed Meteor and restarted it without changing the source files, isobuild doesnāt invoke the build plugins again. So I wasnāt getting my Meteor compiler to re-run until I changed the webpack.config.js files again. Did you find some workaround? Also I was using a hack to get it to restart the server when the server-side webpack bundles were rebuilt, did you find some elegant way to do it?
Yes! You can add any loader to your Webpack configs. You just add ts-loader to packages.json and the loader to your webpack.conf.js on the client and on the server. I havenāt tested it yet but I would be surprised it didnāt work.
Just in case anyone has a problem deleting folders on windows, this is how I delete the npm_modules folders:
npm install rimraf -g
cd packages\npm-container\.npm\package
rimraf node_modules
cd ..\..\..\..
cd .meteor\local\isopacks\npm-container\npm
rimraf node_modules
Well, one of the benefits of meteor is simply āconvention over configurationā - developer experience as first priority. So not really a good place to ask for full control in general.
But Iāll agree regarding some flexibility. Maybe there should be a well balanced default set-up but enable overwrites by dropping them into the app folder - having the build system pick them up when available.
I personally value highly quick developer on-boarding instead of set-up and training in tooling.
Iām very excited, and want to follow this thread. A repo is a great start - a tutorial / video even better :)ā¦ Iām curious - when do you use āimportā - and when do use ārequireā - require only on server Iām guessing ?
Yes, both have value for sure. To some degree the tools could check the Webpack config for overrides, but I think some overrides would have to live outside the Webpack config (for instance preventing some plugins from automatically getting added).
. You can now seamlessly integrate Webpack within your Meteor application.
It took me 4 days morning to night to get this right.
checking it out right now. Seems to work flawlessly. Your webpack:webpack implementation is incredible close to what I started -> kicking out the meteor build process instead of servering files back and forth from a shadow directory.