I’m also in favour of minimal magic. I migrated away from the original expo-cljs-template which had magic that scanned through the code for js/require calls, in favour of maintaining a manual list. The magic approach frequently failed, and didn’t handle comments properly. The frequency of adding a new asset/dependency is relatively low compared to normal coding and magic adds a complexity burden that doesn’t quite feel worth it.
I think the sweet spot is something like what @vikeri said - a semi magic “Maybe you forgot to add x to the require config”.
That’s the sort of thing we have now with a modified figwheel bridge.
Using macros is an interesting idea. Perhaps this could be a separate tiny library, which would mean that it could be used from other build tools.
I don’t think you can have dynamic js/require (I think the bundler does something which is essentially more like a static scan of the source, replacing requires with numerical ids). This is actually one of the areas where clojure can improve on the js experience, because you can create a macro which ends up in a static js/require call that the bundler can use. I’ve experimented with that by making a macro that scans a directory and returns a map of id -> static require calls for images that are available at compile time.
Either way, really glad that this is being looked at - as @vikeri said, it’s pretty much only source maps that are holding us back to switching from figwheel - everything else works much better, and feels much more solid. Thanks for all your hard work on this!