Native browser es6 modules working with phoenix digest

Wondering if anyone has found a way to use mix phx.digest play nicely on a project that uses (modern) browser-native es6 modules (e.g. no webpack/rollup bundling) - with http2 gaining traction using native modules in the browser can be beneficial, but the cache manifest capability of mix phx.digest don’t appear to handle this well.

The problem is the main javascript module app.js imports another module via import ./foo.js and that import statement will need to be replaced with import ./foo.[digest].js. I see that the phoenix digester does do some (limited) search/replace on the .js contents to modify any //# sourceMappingURL=app.js.map at the tail of the modules - was wondering if there is any way to make it also replace the import statements at the top of the module as well?

If not, I guess I’ll need to abandon using mix phx.digest and take the hit of setting up a front end build system (webpack/rollup/brunch) to perform the digest step and then I’ll have to make that system generate a phoenix compatible cache_manifest.json ? Or I guess not use Routes.static_path(...) at all and roll my own helper? Just wondering what approach others have taken.

For reference, the simplest example of this is a new phoenix project with a layout template:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8"/>
    <title>Phoenix Framework</title>
    <script type="module" src="<%= Routes.static_path(@conn, "/js/app.js") %>"></script>
  </head>
  <body>
    <%= @inner_content %>
  </body>
</html>

A primary javascript entry point app.js

import foo from './foo.js'

console.log('app loaded')
console.log('foo is ' + value)

… along with a secondary javascript module foo.js

console.log('foo loaded')
export default 'hello world'

If you run this in production…

> mix phx.digest
> MIX_ENV=prod mix phx.server

You can see (in browser network panel) that the main app.js is loaded via its digested version app.[digest].js , but module.js is loaded by it’s regular name.

Note, I recognize there are pros/cons to native modules vs bundling, but that’s a different topic.