Server bundles may not be needed, but could be used to keep the size of the final build small.

Options:

No Bundling

Don't bundle the server side code, and instead rely on yarn to install the dependencies.
Pros:

• Easier deployment strategy
  Cons:
• Installs a lot more than is needed.
• Longer deploys

Create a Bundle

If we bundle the server side code, then we could just add the compiled and treeshaken code to the list of artifacts instead of the full dependency tree. This should reduce the time required to get the server deployed and started on the production servers.
Pros:

• Deploy just the code that we need
• Don't have to re-install the full list of dependencies.
• Cache the bundle in the list of artifacts of the build, which makes deployment much faster
  Cons:
• Longer build time
• Need to handle cases where modules access files relative to the codes location. (ie, fs.readFileSync(__dirname, './foo.thrift'))

In order to support legacy clients, and to keep the number of transferred files low, we will need to support bundling for the client app.

For development, bundles created via snowpack/esinstall work great, however these may be too granular for production builds. Also, since these bundles are esm, they will not work for legacy builds.

Support bundling for production release.

• Server build - Node 14
• Modern Client - ESM
• Legacy Clients - split bundle

Server Build

A build should be created for the server side that is

Modern Client - ESM

For modern clients, we can rely on the support of ESM + http2 to reduce bundling and initial download size.

Legacy Clients

For clients that do not support ESM (IE) we can vend traditional bundles.