Support Webpack

[morloy]

At Ledgy, we’re running Meteor with a custom webpack build for the client bundle. It’s a big hack, but it works and greatly improves our developer efficiency.
After looking at the new Meteor Roadmap, I noticed that we have already solved most of the points on that list:

• Tree shaking
• Service worker
• Rebuild performance
• Hot module replacement

Other perks that made it worth to switch for us:

• Dynamic import with a strict Content Security Policy (ie. no unsafe-eval)
• Blazing fast checks for circular dependencies and unused exports
• Source maps in production
• Bundling assets directly from node_modules (svg country flags in our case)

Our approach launches both, Meteor and the webpack-dev-server. The dev server handles client rebuilds and HMR, whereas Meteor serves just the “backend”. The full approach is demonstrated in meteor-webpack-starter.

Looking forward to Meteor, it might make sense to embrace webpack as the default bundler. Re-implementing all of the above features looks like a lot of work. Maybe with some tweaking, it is possible to use webpack in a “zero-config” approach.

[benjamn]

Here's my position, which I would rather not reiterate endlessly: meteor/meteor#10811 (comment)

The "other perks" you propose are tiny—and relatively easy to implement, given the will and the resources—compared to the monumental task of replacing Meteor's build system with Webpack, which would leave Meteor a pale shadow of what it is today.

[benjamn]

Here's one of my earliest on-the-record explanations of why Meteor does not use Webpack: https://forums.meteor.com/t/why-is-the-meteor-install-1-3-api-better-than-webpack-in-meteor/14480/3

In short, you're welcome to hack together something that works for you, but hacks don't scale to an entire community. A framework like Meteor has to work for everyone who uses it, in every case.

[Floriferous]

Hey @morloy, while I can appreciate benjamin's stance on this regarding the entire Meteor community, the fact is having HMR and near-instant rebuilds would completely transform our developer experience, and literally improve our bottom-line. It is by (very) far our biggest pain, so I'd love to see a starter repo from you!

[CaptainN]

given the will and the resources

I think this is the main issue. How do we get more folks involved with this aspect of Meteor? I've been around for a while, and I still see that area as opaque compared with WebPack. This might and probably is my own fault, but it might also be a non-technical (or less technical) area to look at to see how we can get more folks involved, and help get the PRs flowing.

[rijk]

I found this an interesting quote as well. We know Tiny has the resources, so... Is the will the problem? 🤔

[yorrd]

We're working on a concept how to do HMR in Meteor, but something else that keeps pointing to webpack is multiple build targets. Is there a workable way at the moment (or planned) to support building multiple bundles out of the one repo of a meteor project?

[benjamn]

@CaptainN If you're interested in working on (re)build performance, this document still holds up, even though it hasn't been updated in a while, and I'm sure you already know a lot of it: https://github.com/meteor/meteor/blob/devel/tools/PERFORMANCE.md

For anyone interested in hot module reloading, I would gently suggest that replacing individual modules at runtime is a deeply flawed programming model that only sort of works in narrow cases (such as replacing a module that only exports a React component), because no one ever goes to the trouble of defining module.hot.accept hooks to handle child module replacement and/or clean up resources allocated by the replaced modules. If you've never heard of Webpack's module.hot API, then I can safely conclude you have been relying on a system that you do not fully understand, which likely fails you in small ways every day, and I would encourage you to think more deeply about the problem of which modules need to be reloaded when a new version of a given module becomes available. It's not easy, and Webpack absolutely has not solved it.

I would also point out that Meteor's client refresh strategy, which reloads all of your CSS and JS without reloading the page or restarting the server, improved greatly in Meteor 1.8.2 (though it does require that you have the autoupdate package installed). And it works in production!

[benjamn]

@yorrd Meteor already does build multiple bundles, without any special configuration:

• web.browser
• web.browser.legacy
• web.cordova
• os.*

… so I'm assuming you mean user-configurable bundles that can be loaded from separate URLs?

[mitar]

user-configurable bundles

That is tracked in: #19

[yorrd]

@benjamn @mitar yes, I'm talking about 100% custom build targets and yes, that's already tracked. Just wanted to reiterate. We're thinking about potentially using this for building only parts of the repo into a microservice according to some biased rules we have here. Is there a better way without user defined build targets?

Would love to see this being advanced

[morloy]

Hey @morloy, while I can appreciate benjamin's stance on this regarding the entire Meteor community, the fact is having HMR and near-instant rebuilds would completely transform our developer experience, and literally improve our bottom-line. It is by (very) far our biggest pain, so I'd love to see a starter repo from you!

With some delay, here it is: https://github.com/morloy/meteor-webpack-starter (the approach is a bit rough, though)