Hello! As part of the effort to make Vue 3 and Meteor work together, I’ve been working on an integration to use Vite instead of Isobuild, opening the whole Vite ecosystem to Meteor.
You can try it here.
This package allows you to put a vite.config.js file in your Meteor app and let Vite handle your client files! (Currently SSR is not tested.)
On paper this means that Meteor can now support any framework such as Vue, Svelte, Solid…
Feedback welcome!
Interesting, do we have some sample projects to help get started?
I’ve tested with Solid in this repo GitHub - Grubba27/solid-meteor-template: Meteor with Solid
Just made the starting list show on the UI.
The results are awesome!
I Will try later with ssr
You should put your Vite entry in imports instead of client folder (it should be different from the Meteor entry) and remove <script src="./main.jsx" type="module"></script> from your html file.
This is Awesome @akryum 
Really great job! Excited to see all the possibilities this opens up for new Meteor configurations! 
Code-splitting/Dynamic import support landed in vite:bundler@0.1.3
Trying to understand what this package does. Is it a full replacement of the meteor bundler but only for the client code?
What features do we lose that are typically provided by meteor isobuild-client? legacy-browser bundles?
Is it a full replacement of the meteor bundler but only for the client code
Yes and no.
Currently SSR is not tested yet. You can see the roadmap here. I haven’t tested Galaxy deployment yet but in theory the built application is standard Meteor so no reason it shouldn’t work.
This still works as expected.
A possible additional benefit of using Vite + Meteor is getting to bypass the use of packages like fourseven:scss that have created some issues for people and seem a bit difficult to maintain going forward from what I’m understanding.
@storyteller and @copleykj might have some other insights to share about the maintainability of foreseen:scss for example. It could be nice to have Vite as a front end bundler that can keep pace with all the client side updates.
Would be cool to see more people in the Community test out this config as a solution.
Vite docs on SCSS here: Features | Vite
fourseven:scss is a pretty popular Meteor Package… curious to see what people think about using Vite to bundle as an alternative.
In case you have a Bootstrap 4 based project that relies on jQuery still, as I do 
This Vite configuration might come in handy or help you out 
Using jQuery based Bootstrap 4 + Vue takes a couple extra additions of code to work perfectly, but I’ve been really happy with the UI/UX, so hope this could help someone else.
Hi @akryum! Does Vite (and this package) automatically handle tree shaking? People have been requesting tree shaking in the Meteor community for a while now, so I thought that might be a feature many people are interested in!
Vite uses rollup for production build, which means it treeshakes unused code by default.
The example doesn’t work. I left a request on github with details. Look please:
Any ideas on when you think SSR will be tested or if anyone has gotten it to work what changes must be made in order to get it working?
My current project uses SSR so I am unable to test this package, I tried it quickly but ran into errors and wasn’t sure what to do or what caused them so I was hoping to see a working sample.
The most important blocker for us to using Vite(more specifically esbuild or swc) is nested imports
@akryum do you have any idea how to handle it?
Nested imports are not standard, basically no tools outside of Isobuild/Reify can understand them.
But since they are mostly useful for conditionally importing stuff with Meteor.isClient or Meteor.isServer, we could statically replace those two expressions and then let Vite treeshake the related imported code:
here is a pic of it working
import { stuff } from './here.js'
if (Meteor.isServer) {
stuff() // Could be tree-shaken on the client
}
Static replace:
import { stuff } from './here.js' // Treeshake
if (false) {
stuff() // Dead code
}
Any other use case should use standard dynamic imports:
if (someCondition) {
const { stuff } = await import('./here.js')
stuff()
}