The all new, all cool version of the ENS manager.
Please note that everything within this repo is currently in alpha. Some contracts are not yet deployed on mainnet which means some functionality may break on the network.
pnpm install
pnpm denv
pnpm dev:glocalpnpm install# For mainnet
pnpm dev
# Or with the test environment running
pnpm dev:glocalpnpm lintpnpm test
pnpm test:watch
pnpm test:coverageWe recommend installing this vscode plugin for a better unit testing experience.
You must have Docker installed to run the test environment. For more information on the environment, see ens-test-env.
Once installed, you can run:
pnpm denvYou shouldn't deploy the subgraph on top of the existing dataset, instead you should create a clean dataset (explained below).
- Start the test environment
pnpm denv --save- Deploy the subgraph
After the deploy scripts have run, you can deploy the subgraph. Assuming you are in the ens-subgraph repo, you can use:
yarn setup- Wait for the subgraph to sync
Similar to the update process, a good indicator of sync status is if you see this message:
no chain head update for 30 seconds, polling for update, component: BlockStream
Dissimilar to the update process however is that you will never need to mine blocks manually.
- Exit the test environment
You can exit out of the test environment using Ctrl+C.
Once exited, you can commit the data to your branch. You do not need to run a separate save command.
Note: You don't need to run the test environment command. It is all handled in the e2e script.
pnpm e2epnpm build
pnpm start
# Or with the test environment running
pnpm build:glocal
pnpm buildandstart:glocalCloudflare will automatically build and deploy a test site when pushed to a new PR branch.
- Install yalc globally:
npm i -g yalc- Run relevant update script within external repo, for example:
# Example publish script for ENSjs, be aware this may have changed.
pnpm publish:local:ensjs- Run pnpm install within this repo:
pnpm installIf updating an existing yalc installation, you can add the --force flag.
The structure of the pages folder is mimicked inside components. Components specific to a page can be found in the the components folder, in the folder corresponding to that page.
Components that are used in multiple places will be found in the top level of the components folder.
Our testing philosophy is user-centric, meaning we want to write out tests so that they resemble the way a user would use our app as much as possible. We've borrowed this from the excellent testing-library.
A user generally clicks, types and swipes, and so most tests should include one of these actions. A user may also load a page in a specific state (by clicking, typing or swiping outside of the app) so sometimes we just want to check a page renders correctly. The vast majority of our tests will be of these kinds.
For deeper parts of the codebase that aren't directly related to a user interaction, such as utility functions, the user is the developer. So simply test the code in the way a developer would use it.
We also primarily test for functionality, making sure the user is able to complete any action that we intend for them to be able to complete. This means we wouldn't write tests to ensure an animation occurs, as that would not stop a user completing an action, and would likely be picked up during the course of development.
Writing out todo tests before implementing a test can help. If I want my form to submit the correct data when I click submit, then I should write it.todo('should submit the correct data when submit is clicked') before starting. This will prevent me from testing implementation details as I write out the component.