feat: testing helpers

[mcansh]

shout out to @jrestall for the initial plumbing, we were both working on this concurrently and came up with similar implementations for todays Remix on React Router 6.3 - I'm currently working on switching this over to use Remix on RR@6.4

Closes: #4488

• Docs
• Tests

Testing Strategy:

• https://github.com/ryanflorence/tmp-form-data-error
• https://github.com/mcansh/stubbbbbs

[changeset-bot]

🦋 Changeset detected

Latest commit: 65bda9d

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 17 packages

Name	Type
remix	Patch
@remix-run/react	Patch
@remix-run/serve	Patch
@remix-run/server-runtime	Patch
@remix-run/testing	Patch
@remix-run/dev	Patch
@remix-run/cloudflare	Patch
@remix-run/deno	Patch
@remix-run/node	Patch
create-remix	Patch
@remix-run/cloudflare-pages	Patch
@remix-run/cloudflare-workers	Patch
@remix-run/architect	Patch
@remix-run/express	Patch
@remix-run/netlify	Patch
@remix-run/vercel	Patch
@remix-run/eslint-config	Patch

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

[ryanflorence]

This is awesome! I made an experimental release to play with it, especially to see if the types and stuff are working well, etc.

A couple of things to look into before we merge:

Types

RouteObject is requiring element but that shouldn't be required, like a resource routes. Pretty much every key on a route object should be optional.

{
  path: "/users",
  loader: () => {
    return []
  },
},

^ That should be fine but TS yells at you for not having an element. I don't know if this is related to this work, or something in @remix-run/router that needs to lighten up.

FormData problems

When testing in vitest with happydom or jsdom we have problems. I'm not completely sure what's going on but this doesn't work:

      <fetcher.Form action="/users" method="get">
        <input
          type="text"
          name="search"
          onChange={(event) => {
            // this works in browsers but not happydom/jsdom
            fetcher.submit(event.target.form);
          }}
        />
      </fetcher.Form>

Both happydom and jsdom fail right here in our fork of web-std-io

• happydom fails our isFormElement check because it returns [object Object] instead of [object HTMLFormElement]. We should open an issue with them.
• jsdom fails because we we don't support passing in a form element to new FormData(form).

Rather than try to support this in our FormData implementation, I think we just need to figure out why the testing environment is even using our backend polyfill for FormData in the first place? It should be using the FormData from happydom/jsdom!

I use a stock Indie Stack, so we can look there to see what's going on.

Here's a repo showing the problem: https://github.com/ryanflorence/tmp-form-data-error

git clone
npm i
npm test
💣

While I know this problem isn't necessarily part of the work in this PR, I'd like to figure this out and fix the test harness in our stacks to make it work before we release so we have the solution from the start.

[mcansh]

RouteObject is requiring element but that shouldn't be required, like a resource routes. Pretty much every key on a route object should be optional.

that's the types in the stub, AgnosticRoutes don't have element, but once RR@6.4 is in here we can re-use that type. for now it's fixed here 2201c47

happydom fails our isFormElement check because it returns [object Object] instead of [object HTMLFormElement].

strange https://github.com/capricorn86/happy-dom/blob/9c0f9b7a7b1363297cf3f4cb2199a430e2a74d1a/packages/happy-dom/test/nodes/html-form-element/HTMLFormElement.test.ts#L16-L20, but yeah looking into why it's not using jsdom's FormData (happydom doesn't have a complete one)

[mcansh]

we're running installGlobals in ./test/setup-test-env.ts

using this works, but i dont think we should need to...?

import { installGlobals } from "@remix-run/node";
import "@testing-library/jest-dom";
import { JSDOM } from "jsdom";

installGlobals()

const jsdom = new JSDOM(`<!doctype html>`);
globalThis.FormData = jsdom.window.FormData;

[mcansh]

removing the installGlobals causes a Request is not defined error, perhaps in @remix-run/testing we have our own installGlobals?

import { installGlobals as installNodeGlobals } from "@remix-run/node";

export async function installGlobals(framework: 'jsdom' | 'happy-dom' = 'jsdom') {
  installNodeGlobals();

  if (framework === 'happy-dom') {
    throw new Error(
      `happy-dom is not currently supported as it doesn't have a FormData implementation`
    );
  }

  let JSDOM = await import("jsdom").catch(() => {
    throw new Error(
      `Could not locate jsdom. Please verify you have it installed.`
    );
  });

  let jsdom = new JSDOM.JSDOM(`<!doctype html>`);
  globalThis.FormData = jsdom.window.FormData;
}

[ryanflorence]

@mcansh yeah let's do that, and if we think of anything better in the meantime, we'll change it when we remove the unstable prefix.

import { unstable_installGlobals } from "@remix-run/testing";
unstable_installGlobals("jsdom");

[mcansh]

sounds good! thats the exact public api i went with for it haha

[ryanflorence]

Wait, what if you're on node 18/19 with jsdom, do you even need to install any globals?

[jrestall]

I've found that when using the jsdom environment on vitest as of version 0.25.3 the FormData workaround is no longer required due to this (vitest-dev/vitest#2290) recent fix. Ryan your repro branch is using the older 0.24.5.

This is great as jsdom setup is quite slow and importing/creating JSDOM again in each test setup after vitest already did it here would likely slow test setup. I haven't tested jest's jsdom environment though.

Wait, what if you're on node 18/19 with jsdom, do you even need to install any globals?

I've found calling installGlobals in a jsdom environment breaks the dom tests due to overwriting FormData. So I have to run the node and jsdom tests separately which isn't ideal. I'd prefer if vitest passed the current environment to the setup files then I could install globals only when running in a node env for action/loader tests.

// maybe one day...
if (globals.environment === "node") installGlobals();