Problem
jspod is the friendly wrapper on JSS — defaults, banner, seedPodFiles() (welcome/signin/account/docs pages), and bundle install. But start() boots JSS by spawning the jss binary:
// lib/start.js:263
const jss = spawn('jss', jssArgs, { ... });
and bootstrap shells out to the CLI too:
// lib/start.js:300
const installChild = spawn(process.execPath, [CLI_SCRIPT, 'install', '--pod', podUrl, '--bundle', 'default'], ...);
Single-process runtimes can't fork a CLI binary — most importantly nodejs-mobile (the embedded Node in the Android app, js-pod/android). So that app had to bypass jspod entirely and call javascript-solid-server's createServer() directly. The cost: it loses all of jspod's onboarding/bundling and drifts off jspod's JSS version (the app is pinned to JSS 0.0.196 while jspod is on 0.0.201).
Ask
Add an in-process mode so jspod can run JSS without spawning, letting mobile/Electron/tests use the same wrapper:
- In-process
start — when spawn isn't viable (opt-in flag, or auto-detect), map the existing jssArgs to createServer(options).listen({ port, host }) from javascript-solid-server instead of spawn('jss'). The option set is already computed; this is "call the library instead of the binary."
- Callable
install — extract the bundle-install logic out of the CLI path (spawn(process.execPath, [CLI_SCRIPT, 'install', …])) into an exported function jspod can invoke in-process.
seedPodFiles() is already a function and the package ships the html + apps/, so onboarding + an offline-first default bundle seed without network.
Payoff
- The Android app (and any embedder) drops its raw-
createServer path + hand-rolled bundle fetch and just calls jspod → inherits onboarding, bundling, and jspod's JSS pin (fixes the version drift).
- jspod stays the single wrapper for every surface: desktop, Termux, mobile, Electron, tests.
Notes
Problem
jspodis the friendly wrapper on JSS — defaults, banner,seedPodFiles()(welcome/signin/account/docs pages), and bundle install. Butstart()boots JSS by spawning thejssbinary:and bootstrap shells out to the CLI too:
Single-process runtimes can't fork a CLI binary — most importantly nodejs-mobile (the embedded Node in the Android app, js-pod/android). So that app had to bypass jspod entirely and call
javascript-solid-server'screateServer()directly. The cost: it loses all of jspod's onboarding/bundling and drifts off jspod's JSS version (the app is pinned to JSS 0.0.196 while jspod is on 0.0.201).Ask
Add an in-process mode so jspod can run JSS without spawning, letting mobile/Electron/tests use the same wrapper:
start— whenspawnisn't viable (opt-in flag, or auto-detect), map the existingjssArgstocreateServer(options).listen({ port, host })fromjavascript-solid-serverinstead ofspawn('jss'). The option set is already computed; this is "call the library instead of the binary."install— extract the bundle-install logic out of the CLI path (spawn(process.execPath, [CLI_SCRIPT, 'install', …])) into an exported function jspod can invoke in-process.seedPodFiles()is already a function and the package ships the html +apps/, so onboarding + an offline-first default bundle seed without network.Payoff
createServerpath + hand-rolled bundle fetch and just calls jspod → inherits onboarding, bundling, and jspod's JSS pin (fixes the version drift).Notes
\p{}regex) regardless — those live in the embedder, since they're about the embedded Node build, not jspod. See Mobile: run JSS on Android via React Native + nodejs-mobile (PoC + portability findings) JavaScriptSolidServer#522 (this is the "jspod-actionable" item there) and Build log + architecture: Solid Pod on Android (RN + nodejs-mobile) js-pod/android#1.spawnas the default for the CLI; in-process is the additive path for libraries.