More documentation updates

CONTRIBUTING.md

@@ -16,33 +16,29 @@ There are many ways to contribute to remote-ui, some of which are:
 
 ### Getting started
 
-Clone this repo, then run `yarn install`. This repo uses [yarn](https://yarnpkg.com) for package management. The codebase is entirely written in [TypeScript](https://www.typescriptlang.org).
-
-### Development tasks
-
-remote-ui uses [loom](https://www.npmjs.com/package/@shopify/loom-cli) for all development tasks. You will see `loom.config.ts` files at the root of the repo, and for each package, which control the way those packages are built, tested, and more.
+Clone this repo, then run `pnpm install`. This repo uses [pnpm](https://pnpm.io) for package management. The codebase is entirely written in [TypeScript](https://www.typescriptlang.org).
 
 #### Type check
 
-Run `yarn type-check`, which will run TypeScript’s `tsc` command on the repo.
+Run `pnpm type-check`, which will run TypeScript’s `tsc` command on the repo.
 
 This repo uses [project references](https://www.typescriptlang.org/docs/handbook/project-references.html), with each package represented as a project, as well as one project for all the non-source code files (tests, config, etc). Make sure you understand how to configure the `tsconfig.json` of projects, like setting the `references` key to include the path to any other packages whose types a given project depends on.
 
 #### Lint
 
-Run `yarn lint`, which will run the entire codebase through [Prettier](https://prettier.io).
+Run `pnpm lint`, which will run the entire codebase through [Prettier](https://prettier.io).
 
 #### Test
 
-Run `yarn test`, which will run all tests in the repo in [jest’s](https://jestjs.io) watch mode.
+Run `pnpm test`, which will run all tests in the repo in [Vitest’s](https://vitest.dev/guide/workspace) watch mode.
 
 Tests are currently a little sparse, focused mostly on ensuring good end-to-end behavior when using all the libraries together. Additional tests can be added for public APIs in each package by including files with a `.test.ts` or `.test.tsx` extension. Make sure you adhere to the structure of the other tests in the repo, and it would be extra appreciated if you understand a little about [Shopify’s approach to front-end testing (sorry to external contributors, this is an internal Shopify link)](https://github.com/Shopify/web-foundations/blob/main/handbook/Best%20Practices/Testing.md).
 
 #### Build
 
-To build all the package outputs for the repo, run `yarn build`. This command builds multiple versions of each package. Some of these versions, like the `.esnext` version of the project you will see, preserve most of the original source code, so that build tools can be configured to parse, process, polyfill, and minify this code in the same way the rest of an application’s codebase. This helps to significantly reduce the bundle size of these packages.
+To build all the package outputs for the repo, run `pnpm build`. This command uses [Rollup](https://rollupjs.org/), with a good set of configuration options provided by [Quilt](https://github.com/lemonmade/quilt/blob/main/documentation/projects/packages/builds.md). Some of these versions, like the `.esnext` version of the project you will see, preserve most of the original source code, so that build tools can be configured to parse, process, polyfill, and minify this code in the same way the rest of an application’s codebase. This helps to significantly reduce the bundle size of these packages.
 
-`yarn build` is automatically run before the project is published. You only need to run it manually when you want to verify the outputs it produces (all of which are ignored in `git`).
+`pnpm build` is automatically run before the project is published. You only need to run it manually when you want to verify the outputs it produces (all of which are ignored in `git`).
 
 ### Contributing a change
 
@@ -53,10 +49,10 @@ If you are fixing a minor issue, feel free to send a pull request directly. If y
 **Before submitting a pull request**, please:
 
 1. Fork the repository and create your branch from `main`
-1. Run `yarn install` from the repository root
-1. Make sure your changes do not cause errors to be thrown when running `yarn test`, `yarn lint`, or `yarn type-check` (these will also be checked automatically when you open your pull request, as they run as part of remote-ui’s [GitHub Action-based CI](./.github/workflows/ci.yml))
+1. Run `pnpm install` from the repository root
+1. Make sure your changes do not cause errors to be thrown when running `pnpm test`, `pnpm lint`, or `pnpm type-check` (these will also be checked automatically when you open your pull request, as they run as part of remote-ui’s [GitHub Action-based CI](./.github/workflows/ci.yml))
 1. Add a description of your changes to package’s `CHANGELOG.md`
-1. Add a [changeset using `yarn changeset add`](#releasing-changes)
+1. Add a [changeset using `pnpm changeset add`](#releasing-changes)
 1. If you haven’t already, [sign a Contributor License Agreement](https://cla.shopify.com/)
 
 #### Contributor License Agreement (CLA)
@@ -67,7 +63,7 @@ Each contributor is required to [sign a CLA](https://cla.shopify.com/). This pro
 
 This repo uses [Changesets](https://github.com/changesets/changesets) to manage releases. As you contribute changes to the repo, you can include changeset files that describe the packages being changed, the significance of the change, and a detailed description.
 
-Before you create a PR for your change, run `yarn changeset`. This command will prompt you to select the packages and type (patch, minor, or major) of change you are working on. You will also be asked for an initial description.
+Before you create a PR for your change, run `pnpm changeset`. This command will prompt you to select the packages and type (patch, minor, or major) of change you are working on. You will also be asked for an initial description.
 
 This command creates a file in the `.changeset` directory at the root of the repo. The contents of these files will be included in the changelog entries of each affected package. If you have additional detail or migration instructions related to the change, you can add it as markdown to the generated file.
 

README.md

@@ -11,9 +11,9 @@ To help you use sandboxed JavaScript environments that are less expensive than a
 - [Preact in a web worker](./examples/preact-web-worker/): an example that uses Remote DOM to render a Preact application inside of a web worker.
 - [Svelte in a web worker, rendered by React](./examples/svelte-web-worker/): an example that uses Remote DOM to render a Svelte application inside of a web worker, which is rendered by a React application on the host page.
 
-## Getting started
+## Building a project with Remote DOM
 
-To use Remote DOM, you’ll need a web project that is able to host two different JavaScript environments: the “host” environment, which runs on the main HTML page and renders actual UI elements, and the “remote” environment, which is sandboxed and renders an invisible version of the DOM that will be mirrored by the host. You can [mix-and-match any combination of “host” and “remote” technologies](#examples) — you don’t need to use a particular JavaScript framework or backend technology to use Remote DOM. If you don’t know how to get started, we recommend starting a [Vite project](https://vitejs.dev) using whatever JavaScript library you prefer, as Vite lets you create `<iframe>` and Web Worker sandboxes with no extra configuration.
+To use Remote DOM, you’ll need a web project that is able to run two JavaScript environments: the “host” environment, which runs on the main HTML page and renders actual UI elements, and the “remote” environment, which is sandboxed and renders an invisible version of the DOM that will be mirrored by the host. You can [mix-and-match any combination of “host” and “remote” technologies](#examples) — you don’t need to use a particular JavaScript framework or backend technology to use Remote DOM. If you don’t know how to get started, we recommend starting a [Vite project](https://vitejs.dev) using whatever JavaScript library you prefer, as Vite lets you create `<iframe>` and Web Worker sandboxes with no extra configuration.
 
 Once you have a project, install [`@remote-dom/core`](./packages/core/), which you’ll need to create the connection between host and remote environments:
 
@@ -65,7 +65,7 @@ Our host is ready to receive elements to render, but we don’t have a remote en
       // We will send this message in the next step.
       window.addEventListener('message', ({source, data}) => {
         if (source !== iframe.contentWindow) return;
-        receiver.receive(data);
+        receiver.connection.mutate(data);
       });
     </script>
   </body>
@@ -102,11 +102,11 @@ Next, let’s create the document that will be loaded into the iframe. It will u
 
 And just like that, the `<span>` we rendered in the `iframe` is now rendered in the host HTML page! You can see a [full example of this example here](./examples/minimal-iframes/).
 
-### Custom elements
+### Adding custom elements
 
 Now, just mirroring raw HTML isn’t very useful. Remote DOM works best when you define custom elements for the remote environment to render, which map to more complex, application-specific components on the host page. In fact, most of Remote DOM’s receiver APIs are geared towards you providing an allowlist of custom elements that the remote environment can render, which allows you to keep tight control over the visual appearance of the resulting output.
 
-Remote DOM adopts the browser’s [native API for defining custom elements](https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_custom_elements) to represent these “remote elements”. To make it easy to define custom elements that can communicate their changes to the host, `@remote-dom/core` provides the `RemoteElement` class. This class, which is a subclass of the browser’s [`HTMLElement`](https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement), lets you define how properties, attributes, and event listeners on the element should be transferred.
+Remote DOM adopts the browser’s [native API for defining custom elements](https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_custom_elements) to represent these “remote elements”. To make it easy to define custom elements that can communicate their changes to the host, `@remote-dom/core` provides the `RemoteElement` class. This class, which is a subclass of the browser’s [`HTMLElement`](https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement), lets you define how properties, attributes, methods, and event listeners on the element should be transferred.
 
 As an example, let’s create a custom `ui-banner` element that renders an appropriately-styled notice banner on the host page. First, we’ll define a `ui-banner` custom element that will render on the host page. This is the “real” implementation, so we will need to implement the element’s `connectedCallback` in order to render it to the screen:
 
@@ -153,7 +153,7 @@ As an example, let’s create a custom `ui-banner` element that renders an appro
 
       window.addEventListener('message', ({source, data}) => {
         if (source !== iframe.contentWindow) return;
-        receiver.receive(data);
+        receiver.connection.mutate(data);
       });
     </script>
   </body>

packages/polyfill/README.md

@@ -1 +1 @@
-# `@remote-dom/signals`
+# `@remote-dom/polyfill`

packages/signals/README.md

@@ -1 +1 @@
-# `@remote-dom/core`
+# `@remote-dom/signals`