Would you be able to provide some thoughts on webpack vs Vite vs SvelteKit? I’m not familiar with any of these beyond the superficial so it would be great to have more input on it.
Also if I remember correctly Vite already has Meteor integration?
Integrating a modern bundler into the Meteor Core is what we need. However, the challenge is how we do.
This post outlines an approach that incorporates sufficient compiler features for any React project. It’s important to recognize that different view libraries have unique needs. I also realized on my tests now that Meteor HMR is no longer functional with this approach. I need to research better ways to solve this and enhance this aspect using my approach.
Thank you for the reference to the meteor-vite tool, which seems promising for our objectives and ensures backwards compatibility with Meteor specific build features. Definitely more complex than my proposal, but the experience is smooth and without sacrificing anything apparently. I’ll invest time in comprehending the proposed solution here, its adventages and limitations.
6 Likes
Generally, for development, I would say Vite is considerably faster, less overwhelming to configure and set up compared to webpack. And unless I’m mistaken, Vite is starting to look like the standard tool these days.
Internally Vite uses Rollup for bundling your app which is what’s comparable to webpack. Vite exposes a subset of Rollup’s configuration options for those that need it, which in most cases ends up being plugin authors, not end users. Whereas webpack again feels more involved and slower to use.
I really couldn’t agree more with Akryum. Transitioning to Vite would most certainly be a huge win for Meteor. Just the HMR alone would make it worthwhile in my eyes. And I think anyone who’ve tried Akryum’s Meteor-Vite plugin would agree. Not to mention the kind of improvement we could see to Meteor’s build times.
Working with older view frameworks, like Vue 2 for example is also a lot nicer compared to the old Meteor ecosystem packages. This is the main reason why I got into maintaining Akryum’s Meteor-Vite package. The boost in development productivity and flexibility has just been incredible.
9 Likes
And I have to agree with Nacho here. An integration into Meteor Core would be very beneficial, and have much less risk of affecting backwards compatibility while providing a better development experience. Definitely a step in the right direction.
But I would love to see this taken further. Right now, while we’re able to provide a great front-end development experience with the Meteor-Vite plugin. Once time comes to bundle for production, build times are still held back by the Meteor bundler bundling its own packages.
That being said - one thing at a time. I think the changes proposed by Nacho is going to provide a significant improvement to the Meteor development workflow. The production build times isn’t that important to be fair, as long as the development experience is good.
6 Likes
@jorgenvatle: It is really nice to have you in this dicussion, your experience and feedback is crucial for us to understand better the benefits of the build tools, but not only in the theorical side, your practical work on meteor-vite is the added value of your input. Similarly goes for @akryum.
Thank you for the quick overview you provided me on meteor-vite. I look forward to adapting the simpletasks example app using meteor-vite and making an analysis based on my simpler approach. This involves tree shaking, ESM support, measuring bundle size gains, testing rollup-plugins, exploring dynamic and lazy imports (Meteor) vs standard imports (Vite), and debugging the packages/plugins in the library you are working on.
I agree on your comments about Vite provinding a better experience, particularly the impressive HMR gains. In my previous attempts, Webpack provided better results in this aspect. However, meteor-vite addresses these issues by enabling the vite-dev server to smartly handle the bundle process and ensure HMR working.
Regarding production builds, while they may require more time due to additional processes, I believe it’s reasonable to expect this, especially initially. As you mentioned, taking one step at a time, prioritizing dev experience, and maintaining backward compatibility with Meteor are key aspects that I believe everyone in this discussion agrees on. With the main objective for Meteor to make a step forward on modernize its building capabilities.
7 Likes
Slighty related to the vite I would also want to express my love for rollup. I use it for all my npm packages in order to build multiple formats from my source:
- esm, cjs, iife, cjs+es5
- normal-size, minified
- sourcemaps for each
It’s fun to work with, config is comprehensible, errors are usually understandable, upgrade minor versions has never broken a thing and plugins work very smooth.
6 Likes
Very interesting thread and tons of information!
I’m wondering if there is a possibility of using pnpm instead of npm speaking about the DX I like the pnpm speed and the way it handles your local disk space. Curious how you @nachocodoner thought about this?
PNPM is usable with Meteor today, you just need to make a little adjustment
1 Like
Nice to see it is somehow working already! But it is not fully integrated yet, right? Would be awesome if it is on the focus for the coming iterations to make this kind of integration easy.
Right now, the main focus is 3.0/Fibers migration once it’s done. This team will be free to make a lot more improvements.
7 Likes
I feel like this is essential for Meteor longevity - I don’t know how much more can be invested into the build tool just to catch up - and we’re missing resources for new features.
My primary deficits with Meteor have been around Cordova, Electron and SSR - if a new bundler can pave the way for that - would be awesome.
7 Likes
My primary deficits with Meteor have been around Cordova, Electron and SSR - if a new bundler can pave the way for that - would be awesome.
Gotta add my voice to this one, especially Electron. I don’t use meteor-electron but it perplexes me that Meteor proudly touts Electron support on its home page yet leaves to die until dd137 intervened. It’s not a good look to have it on the home page when it was on the verge of dying. Not to go too hard on the core team but hopefully this is another issue that can be addressed post 3.0.
1 Like
It actually got me in a lot of trouble with clients. For one, the Cordova version was too old to publish to Android. The other, lots of issues with the (hacky) Electron integration
Last I checked, the Electron integration does not work and the Electron is 10+ major versions behind - so my poor app Color Schemer has not been updated in years. I wouild be willing to pay someone to fix this haha
2 Likes
I do believe --thanks to Doran efforts-- that electron integration is in a much better place, have you tried updating your application recently?
1 Like
I’d like to add another vote to Vite over webpack, in that it seems like it is gaining more widespread usage across stacks.
For example, Remix is basically a Vite plugin now, Adonis uses Vite for compiling frontend assets.
There are also advantageous plugins out there like unplugin-auto-import which could be used to emulate Meteor’s global ambient imports.
5 Likes
Are there alternatives to Electron that would become available, once he build system is open?
Not really a direct alternative, but Capacitor can be deployed as an Electron app, aside from PWA and mobile apps.
Meteor + Capacitor will be a good combination
2 Likes
Coincidentally, when searching about Meteor and Capacitor, @nachocodoner recently posted this about Meteor and Capacitor:
2 Likes
From what I saw, there is an electron-vite integration that could be helpful.
Last I checked, the Electron integration does not work and the Electron is 10+ major versions behind - so my poor app Color Schemer has not been updated in years. I wouild be willing to pay someone to fix this haha
What version is this app running?
Exactly. CapacitorJS provides an alternative to support electron. It offers a plugin to easily generate electron builds within the capacitor bundle.
While I haven’t specifically tested electron integration with CapacitorJS, if proven effective, it could be a cost-free solution for Meteor. I successfully use CapacitorJS in a Meteor app, integrated similarly to the modern bundler approach I discussed in this post, by not altering the core and utilizing scripts for the integration. Meteor produces a Cordova build, considering CapacitorJS compatibility with Cordova, along with some adjustments, the approach becomes feasible. Beyond Meteor 3.x, and as a preparation task I aim to document this in a simpletasks-capacitor repository and initiate a discussion on enhancing Meteor’s native bundler, eventually incorporating this approach into the core.
CapacitorJS automates porting Meteor apps beyond the web, offering a versatile API compatible with any native experience, including PWA. Its incorporation into Meteor as a Cordova replacement would be a significant enhancement, given its nature as a tool for building hybrid apps.
1 Like