Sibling routes - Playground

How sibling routes work

Every playground serves its exported files to its own output. Sibling routes extend that: a playground that shares a host with another open playground also receives that playground's exports, mounted under the other playground's route path. A file the other playground exports at /.js appears in your output at /document/.js when the other playground's route is example/document.

Note: Sibling routes are a playground feature. They work on live editor state, not on deployed state, and RTEdge.net has no counterpart: once deployed, the routes are ordinary deployments and plain URLs reach them.

Requirements

Two playgrounds are siblings when all of this holds:

Both are open in the same browser profile, on the same editor origin.
Each has routes in Code.D.
Any of their routes share a host. example/document and example/color both have the host example.rt.ht.

A playground without routes has no siblings. Set routes in the Code dialog (Set Routes…, Alt+R / ⌥+R), or assign Code.D from io.eval.js or the console:

Code.D = ['example/document']   // in the first playground
Code.D = ['example/color']      // in the second playground

Mounting

A sibling's export /<name> is served in your output at /<sibling route path>/<name>. The path comes from the route in the sibling's Code.D: example/document mounts at /document/<name>, and a route at the host root mounts at /.

This works for relative and absolute same-origin URLs in output documents, such as fetch(), import(), <script src>, <link href> and iframes, and for fetch() inside your playground worker.

Your own routes are in the same index, so your output can also reach its own exports under its route path. With Code.D = ['example/color'], /color/x.js serves your own /x.js, as the deployed URL would.

Example

Two playgrounds, one exporting a module and one importing it:

First playground: example/document

html

<script type=module o:=.js>
  export const hello = name => `Hello, ${name}!`
</script>

Set Code.D = ['example/document']. The module is exported as /.js.

Second playground: example/color

html

<output id=out></output>
<script type=module>
  const { hello } = await import('../document/.js')
  out.value = hello('sibling')
</script>

Set Code.D = ['example/color'] in a second playground while the first one is open. ../document/.js resolves to /document/.js in the output, which the first playground serves. After you deploy both, example.rt.ht/color/ imports example.rt.ht/document/.js through the same relative path.

Rules

Your own files always win, because they are checked first.
Among siblings, the longest matching path prefix owns its subtree. If that sibling does not have the file, the lookup does not fall back to a shorter prefix.
If your playground has routes on several hosts, its routes are tried in Code.D order, and the first host with a matching prefix decides.
Only files are served: a path is looked up in siblings only when its last segment contains a .. Sibling root documents are never served, and sibling workers never run.
A path under a sibling's prefix that the sibling does not export goes on to your own playground worker, if you have one, and then to the network. On the deployed origin that path would belong to the sibling route instead.

When siblings see changes

A playground publishes the exports of its last full output initialization, not the live text of its editor. It publishes them at each full output initialization, each time its routes change, and when another playground on a shared host announces itself. A sibling that receives a snapshot passes it to its output as soon as that output has initialized.

Hot patches do not propagate. After you edit a sibling, its files update when it reloads: press Load (F5), or use a reload trigger such as sync=reload so that every edit reloads it.
Closing a playground removes its files, so its siblings stop serving them.

See Live sync and reloads for the full list of reload triggers.

After deployment

On RTEdge.net each route is its own deployment, and a route answers only for its own directory level. /document/.js belongs to example/document; /document/sub/x.js would belong to a different route, example/document/sub. The sibling mount in the playground follows the same shape, so a relative import that works in two open playgrounds keeps working between the two deployed routes. See Deploying and Exporting files.

Availability

Feature	Playground	RTEdge.net	Notes
Sibling routes	Yes	Not applicable	After deployment the routes are separate deployments reached by ordinary URLs.
Exports of the live playground	Yes	No	Siblings see the snapshot of the last full output initialization.