New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
decouple start code from CLI #14
Comments
Hmmm, Lots of food for thought. I think we should be exporting the following things:
I've updated the readme, turns out watching and listening for SIGHUP is actually much easier than I thought. |
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 ( |
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. |
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)))) |
Opening to continue discussion from #13 (comment)
What do you think about splitting start.js into two files:
start
andupdateWorkerScript
functions, re-exports the worker.js and server.js exports?This would make the following scenario cleaner / less hacky:
The text was updated successfully, but these errors were encountered: