We are currently redesigning the cockpit.js API (like fsinfo), but these are in separate pkg/lib/ ESM modules. These are not currently accessible to standalone plugins.

For our bright future world without bundlers and a Cockpit HTTP 2 or 3 server, we'll get the same problem on our regular pages. Investigate

• if/how we can transpile our .ts files to .js - preferably using tsc, as that is the authority for TypeScript files; or possibly with some other tool, but preferably not with esbuild
  → tsc is fine, it's the reference implementation and works well
• How we can ship these files (cockpit-bridge.rpm? cockpit-ws /static?) so that standalone pages can find and import them
  → it's similar to cockpit.js, so ESMs in cockpit-bridge
• How standalone pages can import them ({{importmap}}s or not?)
  → we don't need importmaps (they break CSP) if the imports are relative; even .ts files need to be imported as ".js", and esbuild will interpret that correctly
• If that isn't possible, we can always fall back to building a barrell file with esbuild
  → let's try without
• Design a versioning schema. It is ok to mark these APIs as "unstable" for standalone pages, but it shouldn't unpredictably break all the time. I.e. a 404 on "cockpit/v4/fsinfo.js" is fine, a random page crash because we broke the API isn't)
  → Let's just start unversioned with lib/ and not break the API too much. If we ever do, we can move to lib2/, but this is expensive. Let's design the new APIs with "options".

We will ship everything in pkg/lib/cockpit/ that is a *.ts file, i.e. no legacy stuff like channel.js.

We keep esbuild for starter-kit and real pages because we use it as a general build system, and sharing PF would reintroduce the versioning/lockstep conflicts we used to have in PF3. Unbundling would not give us significant advantages.