Meteor + Webpack integration - Tree-shaking, Secured code and more

announce
1

Hello everyone!

Some of you may know me, others don’t. As I haven’t posted for a long time, I will take this as a quick presentation. I’m Nacho Codoñer, a former core developer from Pathable platform, which sadly was shutdown as you may already know. I have been developing with Meteor in my entire career, and I have developed much enthusiasm in every part of the software development process.

Currently, I dedicate my time to make to real a dream app, of course using Meteor, but other kind of interesting tooling learned over previous years.

Today I would like to present a straightforward solution that I have on my projects to have Tree shaking, secured code, and other advantages on last compilers features. I am using the best Webpack can offer along with what Meteor delivers.

image
image1920×599 54.7 KB

I used a small repository from the community: fredmaiaarantes/simpletasks.

You can check out this forked repository where I explain it with more details:
https://github.com/freak2geek/simpletasks-webpack

The solution doesn’t rely on modifying the core or creating any Meteor build package as was a previous solution. Instead it keeps a simple solution of script processes and configuration (a bit hacky maybe). I am working with a more advanced project and it works perfectly with much more stuff integrated on the webpack configuration. So I believe it may be useful for some of you, at least the idea that you can go beyond the limits that Meteor imposes if you need.

Surely, when there are any advantages, it comes with its own set of disadvantages, like I’m not using anymore nested imports and dynamic imports using DDP protocol. But for me this is like what is happening with Fibers, non-standard methodologies will become a problem and drive us to reformulate our solutions at some point.

Just that, I hope it is useful for someone and I will try to get more time to share learnings on my way. I am also using CapacitorJS with a similar kind of solution that I hope to validate soon and share with you my journey.

11 Likes
2

What are your thoughts on using Vite? Is Vite a potential replacement for Webpack or are they two different animals?

3

It’s possible that the gains in tree-shaking outweighs the gains of nested/dynamic imports.

It might be possible to create a webpack plugin to leave those nested/dynamic imports as is since meteor will be able to handle those during its bundling process

1 Like
4

I’m posting this question to the community, hoping someone can provide a clear answer. I am not experienced in Vite, the only thing I know is that it is “more performant” in theory because it uses browser native capabilities during development. However, I lack practical experience with Vite’s environment, features, and plugins.

In general, I tend to stick with technologies I already know well instead of adopting new ones to cover capabilities that existing technologies already support. My approach is to maximize the advantages of my existing knowledge rather than chasing the latest hype. Of course, this perspective varies for each individual.

In contrast, I can say which are the strong points of Webpack. The ecosystem of Webpack is so mature and widely adopted, a huge community of developers is behind.

It offers an impressive set of core capabilities, including code splitting (aka dynamic imports), tree shaking, asset management, cache, web workers, advanced minification, and much more; all of these with full customization for advanced usage.

One of the standout features of Webpack is its plugin system. There are some built-in plugins like “Define plugin” for generating secure code bundles, the community also offers a wide array of plugins that can handle almost anything you can imagine, before, during, and after compilation.

Here are some additional examples of useful configurations and extensions:

And much more that you will find over your research.

5

Just a clarification here. Dynamic imports are already supported by Webpack. I have provided additional details on this topic in the repository, available here.
However, the approach Meteor used to apply dynamic imports is not supported so far through this setup. As you suggested, I achieved it through a Webpack’s configuration to ignore import statements and ready on the Webpack’s output for them to be available for Meteor compilation and parsing, but I encountered some issues during production builds. Surely it can be adapted if explored further, but I decided to skip it as the effort required to make it effective didn’t seem justified for my current needs. Webpack’s dynamic imports are enough for my purposes.

Regarding Meteor’s nested imports, I also attempted to replace them with Webpack before and after compilation. However, it didn’t seem worth it for my current needs. I might consider re-attempting this at a later point in time.

1 Like
6

Thanks for sharing the solution with us, Nacho!

It’s amazing to see that we can make Meteor and Webpack work together in such a seamless way. The reduction in size thanks to tree-shaking is very impressive.

3 Likes
7

I went a different direction with React & Meteor. With react-router-dom@6, and using createBrowserRouter with lazy and loading the component and your data in parallel, I was able to achieve even better performance and the bundle size is in kb not mb.

I used this guide as a reference and it works very well with Meteor: Lazy Loading Routes in React Router 6.4+ | Remix

Posting this in case someone wants similar gains and doesn’t use webpack.

4 Likes
8

In an ideal scenario, both dynamic loading (lazy loading) and tree shaking should be available in Meteor.

2 Likes
9

This is fantastic, @nachocodoner! I too am surprised and impressed that Meteor and Webpack can be used together in this way. Thank you for sharing.

I also wanted to say that I am super interested to hear about your experiences with Capacitor someday. :smiley:

1 Like
10

@nachocodoner – this is super interesting! Do you think it would be possible to use the Million.js webpack plugin with this approach?

1 Like
11

I have given a quick attempt to enable it since the setup guide seems to be straightforward. However, I realized that millionjs requires node >15 to work (Meteor currently limited to 14 version). I tested by just running the webpack process with a higher node version, however, I run into other issues.

Definitely it is an interesting configuration to try, but it would be really helpful to finally reach the Meteor node upgrade version which is close in order to facilitate the setup and the inclusion of this kind of modern tooling.

Thank you for sharing this tool, it seems promising, maybe when I have some spare time I will continue my attempt on it.

1 Like
12

I believe the next 3.0 alpha will have support for Node 18. Hopefully it’ll drop soon: Release 3.0 by denihs · Pull Request #12359 · meteor/meteor · GitHub

3 Likes
13

Thanks for the update, really appreciate you spending some time on this. Hopefully we can get there soon with Meteor v3 :pray:

3 Likes