-
Notifications
You must be signed in to change notification settings - Fork 742
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
feat: Create very basic Asset Worker and plumb it into wrangler dev
#6370
Conversation
🦋 Changeset detectedLatest commit: baa45c0 The changes in this PR will be included in the next version bump. This PR includes changesets to release 3 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
9a4f07b
to
e695ec6
Compare
A wrangler prerelease is available for testing. You can install this latest build in your project with: npm install --save-dev https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/10213550282/npm-package-wrangler-6370 You can reference the automatically updated head of this PR with: npm install --save-dev https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/prs/6370/npm-package-wrangler-6370 Or you can use npx https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/10213550282/npm-package-wrangler-6370 dev path/to/script.js Additional artifacts:npx https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/10213550282/npm-package-create-cloudflare-6370 --no-auto-update npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/10213550282/npm-package-cloudflare-kv-asset-handler-6370 npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/10213550282/npm-package-miniflare-6370 npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/10213550282/npm-package-cloudflare-pages-shared-6370 npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/10213550282/npm-package-cloudflare-vitest-pool-workers-6370 Note that these links will no longer work once the GitHub Actions artifact expires.
Please ensure constraints are pinned, and |
89da339
to
33c7761
Compare
packages/wrangler/scripts/deps.ts
Outdated
@@ -22,6 +22,7 @@ export const EXTERNAL_DEPENDENCIES = [ | |||
// and read when we are bundling the worker application | |||
"unenv", | |||
"workerd/worker.mjs", | |||
"@cloudflare/workers-shared/dist", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
marking @cloudflare/workers-shared/dist
in esbuild as external means that "instead of being bundled, the import will be preserved and will be evaluated at run time instead.". This unfortunately comes with the side effect that @cloudflare/workers-shared/dist
won't be considered a dependency, and will therefore be ignored in watch mode. This means that when in dev
mode, any changes to the asset-server-worker
code (or any code inside @cloudflare/workers-shared
for that matter) won't trigger a wrangler re-bundle, which we'd ideally want, since miniflare
references the bundled ASW here.
While this will most likely not impact end-users, since they shouldn't be fiddling with workers-shared/ASW
anyway, it does create some friction for us as the wrangler team, and our dev experience.
One possible solution I played with, that seemed to do the trick, was to factor the rebuilding of ASW in the wrangler dev process, meaning 👇 (with pnpm -C ../workers-shared run bundle:asset-server --watch
being the bit of interest here)
# packages/wrangler/package.json
"dev": "pnpm run clean && concurrently -c black,blue --kill-others-on-fail false \"pnpm -C ../workers-shared run bundle:asset-server --watch\" \"pnpm run bundle --watch\" \"pnpm run check:type --watch --preserveWatchOutput\""
But tbh, I'm not sure how I feel abt that, and since I feel like I'd like to have validation of this work before I spend more time on this, I left it out of my PR for the time being
4b56877
to
a2d887a
Compare
file = path.resolve(getBasePath(), "templates/no-op-worker.js"); | ||
} else if (args.experimentalAssets || config.experimental_assets) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMHO this should be a no-op Worker or the User Worker itself, but never the Asset Server Worker (ASW) or the Router Worker (RW). Let me explain...
The entry-point Worker will be bundled by wrangler
via esbuild, with some very wrangler-specific esbuild configuration. In the process, wrangler
will apply a bunch of middlewares that don't seem relevant to either ASW or RW. wrangler
's esbuild configuration was devised for bundling User Workers specifically, and while ASW and RW are Workers themselves, they are external to wrangler
as a package, are self contained, and will come with their own bundling opinions and requirements. Therefore conflating bundling between the two packages, without an actual need for it, feels very wrong to me. If we want ASW and RW to be common entities to both wrangler and EWC, and to emulate production in dev
as much as possible, ASW & RW should IMO own their own bundling + configuration, and any other devices needed for them to be deployed. To that effect, if wrangler is to have a dependency on these Workers and spin them up in a new Miniflare instance, then it should be on the already bundled versions of these Workers.
This is at least how I see the ideal world, though it remains to be seen if we can pull this off completely. But for now, this is kind of what I'm striving towards.
Happy to hear other thoughts though ^.^
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Totally agree. I was originally thinking we'd just import ASW from "@cloudflare/workers-shared";
from within a template and let Wrangler do it's thing, but you're completely correct — ASW2 should get it's own bundling and that is what we should boot up in miniflare, with separation between this and any user worker stuff.
@@ -879,6 +920,9 @@ export async function buildMiniflareOptions( | |||
proxy: true, | |||
})), | |||
}, | |||
...(config.experimentalAssets |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
technically, for assets-only Workers, we should create a miniflare instance with just the AssetServerWorker here. Removing the entry Worker however broke things, and unfortunately I was kinds clueless as to why. BUT...I might have had a breakthrough in the meanwhile, I just need a bit more time to verify my assumptions & polish the code. I would like to ask that we don't block this PR on that 🙏
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, fine by me. I think we'll eventually get to a place where we're always at least attaching a Router Worker when assets are present, so don't spend too much time getting this running with ASW2 alone.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
indeed, that's kind of the architecture diagram I have in my head as well. The same principle will apply tho, since we'll need to figure out how to make the RW the entry point in the "miniflare pipeline". As it stands right now, that entry point seems to always be the entry-point Worker (which basically wraps the User Worker), so I'll need to have that figured out either way. But again, this can be done as a separate task
wrangler dev
wrangler dev
wrangler dev
wrangler dev
@@ -879,6 +920,9 @@ export async function buildMiniflareOptions( | |||
proxy: true, | |||
})), | |||
}, | |||
...(config.experimentalAssets |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, fine by me. I think we'll eventually get to a place where we're always at least attaching a Router Worker when assets are present, so don't spend too much time getting this running with ASW2 alone.
file = path.resolve(getBasePath(), "templates/no-op-worker.js"); | ||
} else if (args.experimentalAssets || config.experimental_assets) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Totally agree. I was originally thinking we'd just import ASW from "@cloudflare/workers-shared";
from within a template and let Wrangler do it's thing, but you're completely correct — ASW2 should get it's own bundling and that is what we should boot up in miniflare, with separation between this and any user worker stuff.
4ddc962
to
4858991
Compare
a74abdb
to
0ce9eca
Compare
This commit does the ground work needed in order to add Assets support for Workers in `wrangler dev`. Amongst others, it implements the following: - it creates a new package called `workers-shared` that hosts the `Asset Server Worker`, and the `Router Worker`in the future - it scaffolds the `Asset Server Worker` in some very basic form, with basic configuration. Further behaviour implementation will follow in a subsequent PR - it does the ground work of plumbing ASW into Miniflare
0ce9eca
to
baa45c0
Compare
…6370) This commit does the ground work needed in order to add Assets support for Workers in `wrangler dev`. Amongst others, it implements the following: - it creates a new package called `workers-shared` that hosts the `Asset Server Worker`, and the `Router Worker`in the future - it scaffolds the `Asset Server Worker` in some very basic form, with basic configuration. Further behaviour implementation will follow in a subsequent PR - it does the ground work of plumbing ASW into Miniflare
What this PR solves / how to test
[Workers + Assets]
This PR includes work needed to add Assets support for Workers 🚀
Architecture Diagram
Based on the above diagram, this PR does the following:
workers-shared
that will host the Asset Server Worker and Router WorkerThese changes are supported by both
wrangler dev
andwrangler dev --x-dev-env
💅 ...Fixes WC-2423
🐙 Please review per commit 🐙
Author has addressed the following