Vite auto-reload (HMR?)

[jwoertink]

With #912 the memory leak will be gone, but I noticed some weird issues when updating the javascript file.

In development, the main script loads

if I update the src/js/app.js file, it seems like this vite asset server will update, but my app doesn't.

For example, if I just remove all of the Rails stuff, and add console.log("HI"), then I refresh my app page, I won't see the console log. Then I go to http://localhost:3001/src/js/app.js and I'll my code change, but no amount of refreshing will actually run my new code changes. I have to stop the whole lucky server, then restart it to get my changes.

Along with that, if we don't add the type: "module" to the script tag, then it fails because of the import. I was under the impression that it would all be bundled up like what mix did, but maybe that's wrong? We didn't need type: "module" with mix, so I'm not sure if that's something we will just need for Vite, or is that something that only exists for development?

[matthewmcgarvey]

I've been doing a lot of testing today on different things so I just want a single place I can put everything I think I've learned.

Problems

Vite only cares about its inputs

Vite's main thing is that you give it some typescript, javascript, css, or things like that and it will do whatever with it that you've defined, give it a hashed name and put it in the outputdir. With those outputs, it will create a manifest file with the original file name and a reference to the hashed file name to make the connection between the two.

That's great and for the most part exactly what we want. Except, we also want it to do the same for images and any other static assets a dev might put in the public directory. Unfortunately, if it's not in the list of inputs or somehow connected to them (javascript might import them) it will not do the hashed name or include it in the manifest. All it will do beyond the input handling is move anything in the public directory into the output directory. That doesn't work well for Lucky since we require everything to be listed in the manifest file.

Vite dev-manifest plugin doesn't work the same as vite build

For local development, vite provides a dev server to route asset requests to, but doesn't do any of the input processing and doesn't generate a manifest. That's why the vite dev-manifest plugin was added. It will create a manifest though it's formatted differently. The problem is the same as above that the manifest will not include things in the public directory, but it also doesn't process the inputs either at all or in the same way so the manifest didn't include image assets that I imported through javascript for testing. So this causes us to run into the same Lucky requirement around manifests.

Vite dev-manifest output

Vite build manifest (there was a hidden party in the back)

Vite really doesn't like that the output directory is inside the public directory

With the current configuration, vite complains about the setup and I think it also causes issues around asset building. The default setup for vite is that static assets go in public and the vite output goes in the dist directory. I think updating new apps to handle that wouldn't cause a breaking change for existing apps. We'd update the StaticFileHandler in a lucky_cli template to look at the dist directory instead of public.

Potential Solutions

Just deal with the fact that some files aren't in the manifest now

Right now, the workaround for some things not being in the manifest is that with any file not present you need to reference in html with dynamic_asset instead of the asset macro. Things can be done to make those two methods more clear in their usage. This might not be as bad as it sounds. I think the vite-ruby gem does something like this. The default asset_path method looks in the public directory (like our dynamic_asset method) and then the vite_asset_path method is obviously for the vite processed assets.

Update lucky to not require the manifest, and allow building it at runtime

If we accept that we can't build a full manifest in local development, we can add code in lucky to build an asset service that is used where we were pulling things from a hash at compile time with macros. In development, it just adds the vite server url to the front of the asset path. In production it can load the manifest and raise an error on startup if any assets are missing. This would also require that any static assets referenced in html are imported through javascript or css. This is the approach that laravel uses and I've seen most recommended.

Require all static assets used in html to be put in the vite config input list

This would send all images through the pipeline and they'd end up in the manifest. I have not seen anyone recommend this approach in the many places I've looked and I'm not even sure if it works.

[jwoertink]

Just tossing this out there... but what if instead of using Vite as the new default, we looked at https://rolldown.rs/ ? I've never used it, but what if Vite is just doing WAY more than what we need? I think we can use any rollup manifest plugin too like rollup-plugin-manifest... Maybe worth a shot throwing claude at that and just see if it's simpler?

[matthewmcgarvey]

Some one would need to test it out. I have my doubts because of how tied together rollup/rolldown is with vite that it would handle the above issues.

Parcel might be an option. From what I've read it's not as efficient as vite, but with the manifest plugin, it seems to be more in line with how lucky expects things to be.

Another more drastic option is to drop asset bundling and move to import maps like rails is doing

[matthewmcgarvey]

I've done some testing with parcel. Like vite, it doesn't handle static assets out of the box aside from moving them to the output directory, but by making an images.js and importing images there it works. This is largely the same as vite, but the main difference which is beneficial for Lucky is that it creates the manifest even in dev mode. These are my configurations:

.parcel.rc

{
  "extends": "@parcel/config-default",
  "reporters": ["...", "parcel-reporter-bundle-manifest"]
}

package.json

{
  "license": "UNLICENSED",
  "private": true,
  "source": [
    "src/js/app.js",
    "src/css/app.css"
  ],
  "dependencies": {
    "@rails/ujs": "^7.1.0",
    "modern-normalize": "^3.0.1"
  },
  "scripts": {
    "heroku-postbuild": "yarn build",
    "dev": "parcel watch --dist-dir public --public-url /",
    "build": "parcel build --dist-dir public --public-url /",
    "watch": "parcel watch --dist-dir public --public-url /"
  },
  "devDependencies": {
    "parcel": "^2.13.3",
    "parcel-reporter-bundle-manifest": "^1.0.0"
  }
}

"sources" is how you point it to inputs, images.js is imported in app.js but we could probably add it there too

public/parcel-manifest.json

{"js/app.js":"/js/app.js","images/mullet.png":"/mullet.1f0248fb.png","css/app.css":"/css/app.css"}

This was generated by parcel, so it's just an example of the output. In dev mode, the current vite setup points to using the dev server, but parcel's manifest doesn't.

comments

Other than moving public/images/ to src/images/ to import them in src/js/images.js, that is the only configuration I needed.

Like vite, parcel defaults output to dist/ and copies files in public/ over, but since I moved out the images, I had no reason to not keep it simple and point it to the public directory.

[wout]

I meant to chime in earlier but I've been out of the country for business and didn't find the time.

if I update the src/js/app.js file, it seems like this vite asset server will update, but my app doesn't.

Have you loaded the Vite client (@vite/client) in your head? You need that in development to reload your JS modules. (https://github.com/wout/lucky_vite/blob/main/src/lucky_vite/tags.cr#L4-L9).

Along with that, if we don't add the type: "module" to the script tag, then it fails because of the import.

That's because of how Vite works I believe. It serves native ES modules during development so I don't think you can get around that.

Vite really doesn't like that the output directory is inside the public directory

In all of my Lucky projects Vite is outputting to the public dir without issues. It's the default setup of lucky_vite (see also: https://github.com/wout/lucky_vite/blob/main/tasks/cli.cr#L93).

The only issue I still have is that if I add a new file (JS/images/fonts, but not CSS), I need to restart the Lucky app and Vite server. But other than that it just works.

For the lucky_vite shard I looked a lot at vite_ruby and kirby-vite and to be honest, I don't understand it all 100% but it works because I mimicked their setups. 😄

Alternatives

I also feel that Vite is overkill for what's needed in Lucky projects. My only reason to keep it around is HMR, but that could be solved with much simpler tools because we don't need things like frontend framework state preservation for example.

For a while now I've been thinking about eliminating Node.js altogether by using Bun with a simple home-brewed HMR setup. That could be done with probably about 100 lines of JS. Bun has everything built in: WebSockets, bundling, minification, etc., so no or very few dependencies, and it's incredibly fast.

An alternative could be esbuild with a similar setup as above, but it would still require Node.js. I personally find the idea that Bun is a single unit very attractive.

[jwoertink]

Parcel could be nice... I'd also love to see what this whole setup would look like using just bun. That could be really neat if there's no extra special projects required and it's as simple as "install bun and run bun install" 😄

@matthewmcgarvey thanks for putting in the work here and poking around at these. It helps a ton 🙌

[wout]

That could be really neat if there's no extra special projects required and it's as simple as "install bun and run bun install" 😄

Yeah exactly, that's the dream. Having Bun dealing with all asset concerns would simplify things a lot.

To elaborate a bit more on what I have in mind. There would be a bun directory with a few files:

bun/build.js   # bundling
bun/watch.js   # file watcher + ws server
bun/reload.js  # hmr script

It would use simple built-in CSS minification as default and Lightning CSS as an optional system dependency (it's also written in Rust). If it's there, it uses the lightningcss binary, if not just simple regex minification with a tip in the console to install lightningcss for smarter minification.

The bundling, minification, sourcemaps, fingerprinting, and generating the manifest can all be done with Bun without adding a single JS dependency for development.

[jwoertink]

While probably irrelevant now, it looks like the next release of Vite v8 will use rolldown internally by default. I don't think this will solve any of our issues here, but definitely nullifies my comment

[wout]

This weekend I'm going to have a go at the Bun setup I've described above. I already have some of the parts ready but I need to wire it all up and fill in the gaps. As soon as I have something working, I create a repo with a fresh Lucky app using the setup so everyone can have a look to see if it's a viable approach.

[wout]

Small update here. Last weekend I've set up the foundation for this and got a working prototype. This weekend I plan to finalize and polish it a bit so it's presentable. The JS part is about 300 LOC and sourced directly from the Lucky repo.

Here's a small overview:

• Bun is the only dependency
• Zero JS dependencies
• Optional Lighting CSS dependency for smarter CSS parsing, with a fallback to regex minification
• Manifest built via Bun
• Hashed names for production (including fonts and images)
• Shared config between Lucky and Bun (similar to the lucky_vite shard)
• CSS import processing, including from package.json
• Aliases (@js, @css, @images, and @fonts)
• CSS URL rewriting
• Source maps in development
• File watching
• WebSocket reload via Bun
• Hot reload for CSS files, hard reload for JS

It's superfast and zero setup, so if Bun is installed it "just works".

[jwoertink]

wow! That sounds amazing. I mean, even with a big JS file like that, the fact that it's zero dependency is awesome.

Side note, I couldn't imagine what my notifications would look like having one of those usernames 😂

[wout]

Yeah, I'm very excited about this myself 😊. It feels so lightweight and easy compared to the Vite setup. I plan to chop up the JS file in logical entities though just for better readability, like CSS/JS/Server or something.

Side note, I couldn't imagine what my notifications would look like having one of those usernames 😂

@images seems to be free, so you could give it a try 😉