Sort out app bundling and remote module access

[teleclimber]

Some issues we are facing now:

• If app or any part of of app is loaded dynamically, then any remote module may fail unless net access is given.
• One solution is bundling, but then any dynamically loaded module (like migrations) must also be bundled too somehow.

This is very relevant for dev experience.

[teleclimber]

Pro/cons of bundling/not-bundling:

Pro-bundling:

• no dependence on external servers to serve code, it'll always just work. We can expect deno.land/x/ to be there but a custom code server that may go down would cause an app to be uninstallable, which goes against what DS stands for.
• calling out to an external server to get code can reveal IP of DS host, which goes against what DS stands for.
• eliminates typescript as a potential point of failure (meaning that something won't compile even though it would run just fine bc TS changed somehow)

Pro-not-bundling:

• Better dev experience: just write and ship.
• By not bundling, any incompatibilities between lib_support and embedded host code can be detected early.

[teleclimber]

Note that as of 425d612002398dfd90a0ea71a524135b95358741, the app code is loaded statically.

Furthermore, you can expect Deno to have a vendoring feature some day, which could be a big help here.

My current thinking is that apps will be usable without bundling (so long as they do not load remote modules dynamically), but there will also be support (and maybe preference for) apps that have all deps in the vendor dir. It would just be a characteristic of the published app: pre-bundled, or requires accessing external code. Further, anybody can create a bundled version of an unbundled app.

[teleclimber]

Going to close this because not actionable right now because static loading of app is compatible with restrictive allow-net, at least for simple apps.