Proposal: Fingerprint scalaJS assets (optionally!)

[Quafadas]

Intro

For about a year now, I've been using scala JS without a bundler, and I'm enjoying that experience. For me personally, it has kept scalaJS fun.

Predictably, it comes with some downsides vs the mature JS ecosystem - and I've written some of my own tooling https://github.com/Quafadas/live-server-scala-cli-js to cement the issues in my head.

For me the biggest remaining impediment is giving the browser as much help as possible caching assets. When I profiled my scalaJS app page load, CDN dependancies were ready in cca 100ms, the scala JS assets took another 1-2s despite my best efforts returning 304 codes for unchanging files with stable etags. As I understand it, vite circumvents this by fingerprinting assets to provide stable, unique URL's for each component.<hash>.js file. That allows:

• aggressive caching across page reloads, crucially without network requests
• long TTL headers
• correctness guaranteed as the browser will always load a differing hash

Proposal:

After rolling this around in my head, I think Mill would be a great place to implement this (behind a feature flag: jsFingerprintAssets)

• Mill can already rewrite ESModule import paths at link time so that big conceptual hurdle seems already cleared.
• Linker outputs would be re-saved with their content hash originalName.<hash>.js
• Extend the existing Module remapping step to include rewriting internal module imports

Sketch

• Compute a short hash (e.g. SHA-256/8) of each module’s linked output.
• Rename files to include the hash (core.13d4ac9f.js).
• Rewrite internal import statements accordingly.
• Emit a simple manifest.json mapping logical → hashed filenames.
• Clearly: hide behind a feature flag. It should be transparent to the status quo.

Downstream, I hope it could help tooling / app deployment quite significantly.

Benefits

• Long-lived Cache-Control: fearless cache immutability without stale imports.
• Lightning reloads (no 304 revalidation).
• No external bundler

A sort of "vite-lite" experience.

Posting here for discussion. I know maintainer time is limited: I'm proposing to do the work, if there is support and willingness to review / merge. I've been in that part of mill's codebase before, so I think I have a reasonable shot of getting somewhere without being a big burden.

Any opinion / feedback? Could this be viable?

[Quafadas]

It would appear, that there is not interest in this proposal.

[lolgab]

I read it and it's interesting. I forgot to comment.
I wonder if this should be implemented instead as a linker plugin, like https://github.com/armanbilge/scalajs-importmap, which we could then use in Mill (and could be used with Sbt and other build tools).

[Quafadas]

If you're willing to work it through, would be great, but no stress if it's a pain.

To your point, I think it would have to be done at the same time as that import map plugin... it is quite possibly best done as part of that plugin itself!

There's a couple of things I'm not sure how to solve atm. Firstly, I think the algorithm is quite fundamentally stateful. Once we modify the header, it obviously changes the hash of the file contents, which means that if a further module depends on it, it would then hold an invalid reference. So I don't think it's as simple as the ESM remapping.

My biggest unknown is that I think that we'd need to do, is get the Module Graph (I suspect there may potentially be many module graphs emitted at once) from the linker, and traverse each graph in reverse topological order. More or less updating the "import map" after each file is processed. I suspect that is not dissimilar to mill's evaluation model - Just a lot smaller :-).

I'm not sure, whether that's possible without tampering with the linker itself. If you're up for it, figuring out that question on the scalaJS discord is my next step.