[Miniflare 3] Add native support for Windows 🎉 #551
Conversation
|
mrbbot
changed the title
mrbbot
force-pushed
the
tre-native-windows
branch
3 times, most recently
from
cccd3da to
a6bc822
Compare
|
Switching to draft while I figure out what's going wrong with CI... :( |
mrbbot
force-pushed
the
tre-native-windows
branch
9 times, most recently
from
dca740b to
980448c
Compare
|
I think CI should be fixed by fb48926 🤞 See commit descriptions for more details. 🙂 |
| "lint:fix": "npm run lint -- --fix", | ||
| "prepublishOnly": "npm run lint && npm run clean && npm run build && npm run types:bundle && npm run test", | ||
| "test": "npm run build && ava && rimraf ./.tmp", | ||
| "types:build": "tsc", | ||
| "___$comment:types:bundle": "api-extractor doesn't know to load index.ts instead of index.d.ts when resolving imported types", | ||
| "types:bundle": "cp node_modules/@cloudflare/workers-types/experimental/index.ts node_modules/@cloudflare/workers-types/experimental/index.d.ts && npm run types:build && node scripts/types.mjs" | ||
| "types:bundle": "node scripts/copy.mjs node_modules/@cloudflare/workers-types/experimental/index.ts node_modules/@cloudflare/workers-types/experimental/index.d.ts && npm run types:build && node scripts/types.mjs" |
There was a problem hiding this comment.
Why is this change needed? (As an aside, why copy the exportable types into the ambient types?)
There was a problem hiding this comment.
Windows doesn't provide cp, and we'd like to support Miniflare development on Windows too. The problem here is that api-extractor doesn't know to load index.ts instead of index.d.ts when importing types.
There was a problem hiding this comment.
Ah okay—is there on issue for that on the api-extractor repo that could be linked?
There was a problem hiding this comment.
I think this might actually be a fundamental restriction of API extractor, it only processes .d.ts files. From https://api-extractor.com/pages/setup/invoking/:
This enables generation of the .d.ts files that API Extractor will analyze. By design, TypeScript source files are not directly analyzed, but instead must be first processed by your compiler.
It just so happens in our case, that our .ts files are effectively .d.ts files with additional export statements.
|
This is really exciting! Mostly just a couple questions |
As of cloudflare/workerd#452, `workerd` supports Windows' natively. This change upgrades `workerd`, then removes the WSL and Docker runtime shells. It also `Cherry`picks #509, to allow Miniflare development on Windows too.
...and disable keep-alives. This was a debugging step, but is probably a good thing to do anyway. We're making lots of repeated requests here, `http` is probably more optimised than `undici` atm. In most cases, the socket will be closed as `workerd` won't be listening yet, so keep-alives don't make sense.
When `workerd` sends a request to Miniflare's loopback server, we convert the incoming request to an `undici` `Request` object. Previously, we passed the incoming request object directly to the `new Request()` constructor. Internally, `undici` created an async iterator from this request body stream. Unfortunately, if `workerd` ever aborted one of these requests (e.g. disposing runtime with a pending `waitUntil`ed `fetch`), this abort error would be propagated to the async iterator, and cause an unhandled rejection. We now convert this incoming request to a `ReadableStream` ourselves, catching errors from this async iterator, gracefully closing the stream.
Building on the previous commit, avoid sending requests that might be aborted in tests, because they're `waitUntil`ed. Without this, we could end up with an incomplete JSON body that can't be parsed.
mrbbot
force-pushed
the
tre-native-windows
branch
from
8332402 to
365cb10
Compare
As of cloudflare/workerd#452,
workerdsupports Windows natively. This change upgradesworkerd, then removes the WSL and Docker runtime shells. It also Cherrypicks #509, to allow Miniflare development on Windows too.