-
Notifications
You must be signed in to change notification settings - Fork 758
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
test(unenv-preset): move tests from nodejs-hybrid-app #7700
Conversation
|
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/12692667361/npm-package-wrangler-7700 You can reference the automatically updated head of this PR with: npm install --save-dev https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/prs/7700/npm-package-wrangler-7700 Or you can use npx https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12692667361/npm-package-wrangler-7700 dev path/to/script.js Additional artifacts:wget https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12692667361/npm-package-cloudflare-workers-bindings-extension-7700 -O ./cloudflare-workers-bindings-extension.0.0.0-v7e2886048.vsix && code --install-extension ./cloudflare-workers-bindings-extension.0.0.0-v7e2886048.vsix npx https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12692667361/npm-package-create-cloudflare-7700 --no-auto-update npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12692667361/npm-package-cloudflare-kv-asset-handler-7700 npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12692667361/npm-package-miniflare-7700 npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12692667361/npm-package-cloudflare-pages-shared-7700 npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12692667361/npm-package-cloudflare-unenv-preset-7700 npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12692667361/npm-package-cloudflare-vitest-pool-workers-7700 npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12692667361/npm-package-cloudflare-workers-editor-shared-7700 npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12692667361/npm-package-cloudflare-workers-shared-7700 npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12692667361/npm-package-cloudflare-workflows-shared-7700 Note that these links will no longer work once the GitHub Actions artifact expires.
Please ensure constraints are pinned, and |
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.
I'm a bit confused about the testing strategy here.
It seems that you are compiling a Worker in order to then run it via wrangler dev
. Is that right? Why do that rather than just point Wrangler at the Worker directly, telling it to use the different unenv preset?
if (isWindows) { | ||
return; | ||
} |
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.
Can you not just use describe.skipIf(isWindows)
rather than adding this in every hook and test?
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.
Actually, is it not possible to make these tests work on Windows?
You say that MINIFLARE_WORKERD_PATH is not supported on Windows. Is that strictly accurate or is it that you just need to specify a different path for Windows (e.g. "node_modules/.bin/workerd.cmd"
or "node_modules/.bin/workerd.ps1"
)?
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.
Can you not just use describe.skipIf(isWindows) rather than adding this in every hook and test?
TIL - that's much nicer, thanks for the tip.
Actually, is it not possible to make these tests work on Windows?
That's what I saw in miniflare tests - see the link in the PR description.
I don't think it would add much value anyway as we are already testing on Max + Ubuntu?
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.
I think that comment in Miniflare is not the same thing. What they are saying there (I believe) is that their test uses a shebang binary to trigger workerd, which would not work on Windows. But when you install workerd it should provide a Windows compatible binary, which usually ends in .cmd or .ps1, and that ought to work in this scenario.
I am not convinced that testing on Max+Ubuntu is adequate to ensure Windows compatibility 😆
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.
I am not convinced that testing on Max+Ubuntu is adequate to ensure Windows compatibility 😆
What I mean is that I don't really care about the dev version working on Windows because I don't think any use of dev on Windows. Wrangler is tested on windows which should be what matters.
But I'll see if there is something I can do without spending too much time.
packages/unenv-preset/tests/build.ts
Outdated
|
||
console.log(pkgDir); | ||
|
||
execSync(`node ${wranglerPath} deploy --dry-run --outdir ./dist/worker`, { |
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.
Sorry to be dumb but why are we building a Worker here?
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.
That the same thing we do for nodejs-hybrid-app
in the "build": "wrangler deploy --dry-run --outdir=./dist",
That is we need to serve the worker for the tests.
We have to execSync
here to override the resolution base folders (via WRANGLER_UNENV_RESOLVE_PATHS
).
That's a good question, I'll add a comment to the file.
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.
In the fixture I believe Igor added the build
script so that when we run pnpm build
at the root of the monorepo it will run the build on that fixture and check that the build completes. Other than that we don't use it at all. But moreover "building" the fixture makes sense - it literally is the Worker.
But here, I feel this is conflating testing with the package itself. The build script should be building the preset package not the fixture used for testing it. To be honest I would rather we kept all these tests in the nodejs-hybrid-app fixture and enabled being able to build and test that fixture against the workspace builds of the preset rather than partially duplicating the tests across the package and the fixture.
Yep that should work too. I only did what edit: At least it's easy to inspect the generated file to check that resolution works well |
OK. So I forgot that we have this problem with when we bump the unenv version in Wrangler. I think we should drop that extra build from the preset package build command, and allow the developer to run it independently if they want. Or if we want to actually have that as a test do the build as part of a test. I still think we should try to test on Windows. While it might not be part of a CF developer's daily workflow, it would be annoying to find that an unenv preset change breaks on Windows only after we try to bump the preset version in Wrangler. |
5985bd3
to
d1b2ffe
Compare
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.
A couple of suggestions.
@@ -29,8 +28,6 @@ export default { | |||
return testX509Certificate(); | |||
case "/test-require-alias": | |||
return testRequireUenvAliasedPackages(); | |||
case "/test-unenv-preset": | |||
return await testUnenvPreset(); |
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.
Given that the testing strategy is now to test local changes to the unenv preset in the package, it might be worth keeping this test here so that we also get test coverage on the published unenv preset?
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.
I think it makes sens to have preset related tests in the @cloudflare/unenv-preset
and in a single location (I don't think we will think about updating 2 places especially because they should not be updated at the same time)
An improvement I want to do (as a follow up) is to test both the stable and dev versions from the preset package. This is why I asked James and Yagiz about figuring out the workerd version at runtime (to only run applicable tests). It sounds like it is not possible but we can still pass the version via the request.
1522194
to
625937e
Compare
67bd34c
to
1ae5839
Compare
@petebacondarwin thanks a lot for your patience and insights with this review. I ended up disabling windows tests (adding a comment with the link to the relevant Node issue). Let me know if there is more to do here. 🙏 |
yay! |
Move the tests from nodejs-hybrid-app
The tests are executed with the dev version of
@cloudflare/unenv-preset
and the pkg local version ofworkerd
(instead of the pinned versions that will be used by wrangler).Note that currently wrangler still uses the cloudflare preset from
unjs/unenv
so that is what is tested for now. Once wrangler switches to using@cloudflare/unenv-preset
the resolution override will be in effect (we are trying to resolve$clouflare.ts
files that are not in@cloudflare/unenv-preset
)Tests are disabled on Windows as
MINIFLARE_WORKERD_PATH
is not supported./cc @pi0