decouple start code from CLI about cloudflare-worker-local HOT 4 CLOSED

I think this will probably be the direction we go in. As a start, I've opened #19, which just exports (by default) Worker and createApp.

from cloudflare-worker-local.

If you want to use chokidar, the new pseudocode would look something like this

const {createApp} = require("cloudflare-worker-local")

const app = createApp(fs.readFileSync("/path/to/worker.js"), {})
app.listen(3000);

chokidhar.watch("/path/to/worker.js")
  .on('change', () => fs.readFile('/path/to/worker.js', buffer => app.updateWorker(bufferToString(buffer))))

from cloudflare-worker-local.

Hmmm, Lots of food for thought. I think we should be exporting the following things:

• startServer(pathToWorker, {port}) (this automatically will updating the worker on SIGHUP)
• Worker
• startTestServer(workerContents, upstreamBehavior)

I've updated the readme, turns out watching and listening for SIGHUP is actually much easier than I thought.

from cloudflare-worker-local.

In my experience so far using cloudflare-worker-local with packagers like parcel and rollup, nodemon hasn't worked well. It leads to complex npm scripts to ensure the packager has built the worker script prior to starting cloudflare-worker-local. Similar to remy/nodemon#1297 and remy/nodemon#797.

The sighup approach seems to be ok for scenarios where the worker source code is a single javascript file.

For increased flexibility I think it would be great if the CLI related logic (process.argv, SIGHUP and fs.readFile(pathToWorker)) was decoupled from the core logic (start server / update worker).

from cloudflare-worker-local.