-
Notifications
You must be signed in to change notification settings - Fork 189
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
feat(create-mud): use new sync packages #1214
Conversation
🦋 Changeset detectedLatest commit: d4984cc The changes in this PR will be included in the next version bump. 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 |
363c885
to
9858d12
Compare
2. In your `supportedChains.ts`, replace `foundry` chain with our new `mudFoundry` chain. | ||
|
||
```diff | ||
- import { foundry } from "viem/chains"; | ||
- import { MUDChain, latticeTestnet } from "@latticexyz/common/chains"; | ||
+ import { MUDChain, latticeTestnet, mudFoundry } from "@latticexyz/common/chains"; | ||
|
||
- export const supportedChains: MUDChain[] = [foundry, latticeTestnet]; | ||
+ export const supportedChains: MUDChain[] = [mudFoundry, latticeTestnet]; | ||
``` |
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.
is this part still necessary? or do we want to keep it so we can add stuff to mudFoundry
in the future?
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's worth keeping for now since we've discovered a couple reasons to hook into viem internals
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 reason to keep it: wevm/viem#1006
- : world?.blockNumber ?? -1; // -1 will attempt to find the block number from RPC | ||
+ : world?.blockNumber ?? 0n; |
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.
do we currently have some mechanism to look for the HelloWorld
event? or load it from the worlds.json
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.
nvm world?.blockNumber
already grabs it from the worlds.json
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 imagining in the future syncToRecs
will attempt to find a HelloStore
event emission (which will also have things like protocol version)
Co-authored-by: alvarius <alvarius@lattice.xyz>
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.
big props on this changeset, this is by far the best changeset we have so far
// KeysWithValue doesn't seem to like singleton keys | ||
// modules: [ | ||
// { | ||
// name: "KeysWithValueModule", | ||
// root: true, | ||
// args: [resolveTableId("CounterTable")], | ||
// }, | ||
// ], |
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.
will be solved by #1125
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.
LFG 🎉
Updates all templates to use new sync packages
Waiting on wevm/viem#963 so we don't need zero-fee overrides everywhere