Minification from Vite

[dispbd]

Hello @JorgenVatle

We recently optimized the project and wanted to get rid of unnecessary dependencies. I thought that since Vite builds the client, the standard-minifier-js and standard-minifier-css packages are no longer needed (after all, they are only needed to minify the client). But it was not so.
As I understand it, the meteor-vite plugin does not minify third-party client code (packages folder, etc.).
Moreover, as I understand it, meteor-vite generally ignores the minification settings, since nothing changed when these settings were changed:

How much do you think it makes sense to bypass the built-in minification (that is, minify the client code after the meteor build stage)? Will this give any advantage in build speed? or will the benefit be minimal due to the complexity of the assembly process and the structure of the assembled meteor code?

[JorgenVatle]

With the way Meteor-Vite is currently set up, I'm not sure if there would be much benefit to running a Vite minification step after the Meteor build.

---

The full Meteor-Vite build process looks something like the following:

1. Analyze all module imports starting from Vite entrypoint file configured in vite.config.js
2. Substitute any imports for Atmosphere packages with a lightweight ESM shim that calls the require() function shipped to browsers in Meteor's client bundle. Essentially, the source code for those packages is omitted from the Vite bundle, it's handled something like an externalized dependency.
3. Attempt to compile everything from your Vite client entry into a single module. Dynamically imported modules will be split into separate chunks that'll be served to your users when needed by Meteor's dynamic import implementation.
4. Transpile the Vite bundle's .js files for Meteor using Meteor's default Babel config.
   • Judging from the to-dos left by Akryum, this could potentially be replaced by esbuild. I'll see if I can include some timings for this build step so we can determine whether there's any build time to be saved there.
5. Feed the transpiled sources and any non-CSS/JS assets into the Meteor production bundle using a compiler plugin and let Meteor do the rest. This would be where your minification plugins like standard-minifier-js and standard-minifier-css take over if I'm not mistaken.

When I first got into working on Meteor-Vite I was thinking it could act as a replacement to the Meteor build system. But it doesn't seem like Vite would be a good fit for that. Optimally, we would have Vite take care of both the client and server-side builds. But from what I can gather, Vite isn't really intended to be used as a build tool for the server. I imagine esbuild would be the better option here.

Assuming most of the build time is spent after the Meteor-Vite build step has completed, the best solutions I can think of would be to either;

1. Lean into Meteor's build system - using a separate build plugin to take over after the Vite compilation stage, something like an esbuild-powered standard-minifier package.
2. Just build the client bundle independently of Meteor. Which should be totally doable now that the meteor-vite npm package ships with a standalone Vite plugin that takes care of most of the work previously done by the vite:bundler Atmosphere package. Then it kind of is up to how long Meteor takes to build the server bundle.

---

One important thing to check would be the Meteor client mainModule file referenced in your package.json. This file should ideally be empty apart from some Atmosphere package imports to ensure lazy-loaded packages won't be omitted from your client bundle.

If your Meteor client entry does have imports for application code, it's easy to end up with code that's included twice - once in your Meteor client bundle, and another in your Vite client bundle. Which will naturally slow down the build process and bloat your final production bundle.