You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 3, 2023. It is now read-only.
I did some digging and it appears right now using wrangler dev with wrangler.toml of type = "javascript" is a bit awkward at the moment because if you are using some other build process (e.g. rollup) it won't be run as part of it, nor after the watcher notices any changes.
It's unclear what the ideal solution would be since it would likely depend somewhat on how things work on the hood. The workaround I'm using is to have two terminals open: one that is watching the files and rebuilds the JS, and the other that runs wrangler dev concurrently, which picks up the new built output. This hasn't been the worst DX, but it's less than ideal as it trips up other devs, who get confused that they need to run simultaneously and you must wait for the first build to finish before doing wrangler dev otherwise it won't start since the output isn't there yet.
An obvious option might be to allow a custom build script to be provided in the wrangler.toml that gets run after file changes are detected, but this also isn't ideal because some build tools perform better in their own custom watch modes instead of calling their build command repeatedly.
Another option might be to run the custom build command once, and it can use its own watcher.
Then dev mode just needs to watch for changes to the output artifact alone. This may be problematic for reasons I haven't considered, though.
Somewhat related is that if this is ever supported it might want to work similarly for the other commands.
The text was updated successfully, but these errors were encountered:
I'm doing more stuff with workers now as well and thinking of a small build pipeline but webpack is overkill for me. What I want is Typescript + Rollup which I've set up a few times already and am familiar with, but there's no possibility to do this in a good way yet.
I think this could be as simple as a "prepare" hook, similar to how it works with npm scripts. Maybe that is actually a pretty straight-forward solution?
Then all you need to do under the hood is spawn a process that runs npm run ${prepare_script} and waits for it to finish, and this can be hooked into any of the commands (dev, publish, etc.), similar to how it's done with webpack. I'm not sure how well that works in combination with the file watching, but this is the kind of API I'm looking for.
💡 Feature request
Overview and problem statement
I did some digging and it appears right now using
wrangler dev
with wrangler.toml oftype = "javascript"
is a bit awkward at the moment because if you are using some other build process (e.g. rollup) it won't be run as part of it, nor after the watcher notices any changes.It's unclear what the ideal solution would be since it would likely depend somewhat on how things work on the hood. The workaround I'm using is to have two terminals open: one that is watching the files and rebuilds the JS, and the other that runs
wrangler dev
concurrently, which picks up the new built output. This hasn't been the worst DX, but it's less than ideal as it trips up other devs, who get confused that they need to run simultaneously and you must wait for the first build to finish before doingwrangler dev
otherwise it won't start since the output isn't there yet.An obvious option might be to allow a custom build script to be provided in the wrangler.toml that gets run after file changes are detected, but this also isn't ideal because some build tools perform better in their own custom watch modes instead of calling their build command repeatedly.
Another option might be to run the custom build command once, and it can use its own watcher.
Then dev mode just needs to watch for changes to the output artifact alone. This may be problematic for reasons I haven't considered, though.
Somewhat related is that if this is ever supported it might want to work similarly for the other commands.
The text was updated successfully, but these errors were encountered: