Unify server runtime packages via Node.js conditional exports

[tylerbrostrom]

Background

Release 1.4.0 got rid of magic imports (thank goodness!)

Instead of importing server-side helpers like json from remix, you now import them from one of the following:

• @remix/deno
• @remix/cloudflare
• @remix/node

These packages either re-export or re-implement stuff from the @remix/server-runtime package.

Point is, they’re mostly the same API surface…

…there exists additional stuff (e.g. createCloudflareKVSessionStorage from @remix/cloudflare)

Assertion

APIs common to these packages (i.e. stuff from @remix/server-runtime) should be consolidated and implemented in a single package.

Platform-specific APIs would remain in their respective packages (e.g. createCloudflareKVSessionStorage stays in @remix/cloudflare).

Why?

1. As a user, I shouldn’t have to care about an API’s implementation. import {...} from '@remix/cloudflare' vs import {...} from '@remix/node' is not my concern.
2. It’s possible. Node.js conditional exports provide a mechanism for signaling build targets to bundlers.
3. It’s feasible. Remix owns it’s bundling process (esbuild). esbuild understands conditional exports and can be configured to understand non-standard conditions (e.g. cloudflare-workers). That bundling logic would be a cinch to implement, using the the config option serverBuildTarget.
4. Server runtimes are slowly-but-surely converging on web standards—as evidenced with fetch landing in Node.js. The need for separate implementations may eventually dissipate, leading to duplicate implementations across packages. Deno and Cloudflare implementations are already very similar if not identical.