Skip to content
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

chore: add a test harness for <Dev/> #615

Merged
merged 1 commit into from
Mar 16, 2022
Merged

chore: add a test harness for <Dev/> #615

merged 1 commit into from
Mar 16, 2022

Conversation

threepointone
Copy link
Contributor

This adds a basic test harness for the <Dev/> component. We'll add more tests and flesh out the harness a little more later, but figured we could land this and iterate on it.

@changeset-bot
Copy link

changeset-bot bot commented Mar 16, 2022

⚠️ No Changeset found

Latest commit: 35292f9

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@github-actions
Copy link
Contributor

github-actions bot commented Mar 16, 2022

A wrangler prerelease is available for testing. You can install this latest build in your project with:

npm install --save-dev https://prerelease-registry.developers.workers.dev/runs/1991347362/npm-package-wrangler-615

You can reference the automatically updated head of this PR with:

npm install --save-dev https://prerelease-registry.developers.workers.dev/prs/615/npm-package-wrangler-615

Or you can use npx with this latest build directly:

npx https://prerelease-registry.developers.workers.dev/runs/1991347362/npm-package-wrangler-615 dev path/to/script.js

@threepointone
Copy link
Contributor Author

wip while I work through some issues I see with this

@@ -586,8 +579,9 @@ function useEsbuild({
// esbuild already logs errors to stderr and we don't want to end the process
// on build errors anyway so this is a no-op error handler
});

return stopWatching;
return () => {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

React ignores subsequent setups of the cleanup callback, so this needs to be a function on first run. I'm surprised there was no warning thrown here, I kinda remember us working on it back then. Might've been lost at some point.

@@ -126,6 +126,12 @@ export default function createModuleCollector(props: {
),
},
async (args: esbuild.OnResolveArgs) => {
if (
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we specifically want to avoid entry points here

@@ -448,35 +447,29 @@ function useLocalWorker(props: {
return { inspectorUrl };
}

export interface DirectorySyncResult {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The types for tmp.dirSync call are wrong, so we redefined it here. I'll send a fix upstream soon.

</ink-box>
`);
await TestRenderer.act(async () => {
// TODO: get rid of these sleep statements
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The proper way to do this is to hook into the async process internally and listen when they shut down etc. That'll take some work, that I'll do soon.

@petebacondarwin
Copy link
Contributor

Very excited to see this work in progress @threepointone. Great stuff!

@threepointone
Copy link
Contributor Author

Let's land this and we can iterate on more stuff, don't want to keep rebasing as changes are being made to the rest of Dev elsewhere

@@ -149,35 +148,29 @@ function Dev(props: DevProps): JSX.Element {
);
}

export interface DirectorySyncResult {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The types for tmp.dirSync call are wrong, so we redefined it here. I'll send a fix upstream soon.

@@ -84,7 +84,9 @@ export function useEsbuild({
// on build errors anyway so this is a no-op error handler
});

return stopWatching;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

React ignores subsequent setups of the cleanup callback, so this needs to be a function on first run. I'm surprised there was no warning thrown here, I kinda remember us working on it back then. Might've been lost at some point.

Copy link
Contributor

@petebacondarwin petebacondarwin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's go go go

@@ -84,7 +84,9 @@ export function useEsbuild({
// on build errors anyway so this is a no-op error handler
});

return stopWatching;
return () => {
stopWatching && stopWatching();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NIT:

Suggested change
stopWatching && stopWatching();
stopWatching?.();

/>
);
});
// @ts-expect-error How do I avoid the "used before assigned" error?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe you just need to specify the type as undefinable...

let instance: TestRenderer.ReactTestRenderer|undefined;

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sweet, that works!

@@ -122,7 +124,8 @@
"node_modules/(?!find-up|locate-path|p-locate|p-limit|yocto-queue|path-exists|execa|strip-final-newline|npm-run-path|path-key|onetime|mimic-fn|human-signals|is-stream|get-port)"
],
"moduleNameMapper": {
"clipboardy": "<rootDir>/src/__tests__/helpers/clipboardy-mock.js"
"clipboardy": "<rootDir>/src/__tests__/helpers/clipboardy-mock.js",
"miniflare/cli": "<rootDir>/../../node_modules/miniflare/dist/src/cli.js"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Out of curiosity, why is this needed? Is it because of calls like:

require.resolve("miniflare/cli")

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's exactly it. jest hijacks the module loader so it can do stuff like mocks, but looks like it struggles with this specific call (because it's an es import? maybe, dunno.)

This adds a basic test harness for the `<Dev/>` component. We'll add more tests and flesh out the harness a little more later, but figured we could land this and iterate on it.
@threepointone threepointone merged commit 6be530b into main Mar 16, 2022
@threepointone threepointone deleted the test-dev branch March 16, 2022 07:40
mrbbot added a commit that referenced this pull request Oct 31, 2023
Miniflare starts its loopback server on the same host as the
`workerd` server, so it's accessible on all the same addresses as the
runtime. This allows the loopback server to be the target for the
live reload web socket. This means if the `host: "localhost"` option
is set, we start a Node `http` server with `localhost` as the
hostname. Node will perform a DNS lookup to work out which IP address
and interface to listen on, but will only listen on the first entry.
In Node 17+, this will be the IPv6 interface. Unfortunately, we
previously hardcoded the loopback address as the IPv4 loopback,
meaning `workerd` was unable to connect. This change switches to
using `localhost`, which `workerd` will resolve to either IPv4 or v6.

Closes #3515
mrbbot added a commit that referenced this pull request Nov 1, 2023
Miniflare starts its loopback server on the same host as the
`workerd` server, so it's accessible on all the same addresses as the
runtime. This allows the loopback server to be the target for the
live reload web socket. This means if the `host: "localhost"` option
is set, we start a Node `http` server with `localhost` as the
hostname. Node will perform a DNS lookup to work out which IP address
and interface to listen on, but will only listen on the first entry.
In Node 17+, this will be the IPv6 interface. Unfortunately, we
previously hardcoded the loopback address as the IPv4 loopback,
meaning `workerd` was unable to connect. This change switches to
using `localhost`, which `workerd` will resolve to either IPv4 or v6.

Closes #3515
mrbbot added a commit that referenced this pull request Nov 1, 2023
Miniflare starts its loopback server on the same host as the
`workerd` server, so it's accessible on all the same addresses as the
runtime. This allows the loopback server to be the target for the
live reload web socket. This means if the `host: "localhost"` option
is set, we start a Node `http` server with `localhost` as the
hostname. Node will perform a DNS lookup to work out which IP address
and interface to listen on, but will only listen on the first entry.
In Node 17+, this will be the IPv6 interface. Unfortunately, we
previously hardcoded the loopback address as the IPv4 loopback,
meaning `workerd` was unable to connect. This change switches to
using `localhost`, which `workerd` will resolve to either IPv4 or v6.

Closes #3515
mrbbot added a commit that referenced this pull request Nov 1, 2023
Miniflare starts its loopback server on the same host as the
`workerd` server, so it's accessible on all the same addresses as the
runtime. This allows the loopback server to be the target for the
live reload web socket. This means if the `host: "localhost"` option
is set, we start a Node `http` server with `localhost` as the
hostname. Node will perform a DNS lookup to work out which IP address
and interface to listen on, but will only listen on the first entry.
In Node 17+, this will be the IPv6 interface. Unfortunately, we
previously hardcoded the loopback address as the IPv4 loopback,
meaning `workerd` was unable to connect. This change switches to
using `localhost`, which `workerd` will resolve to either IPv4 or v6.

Closes #3515
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants