-
Notifications
You must be signed in to change notification settings - Fork 181
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
refactor(cli): split up deploy into modules #1384
Conversation
|
Thank you for picking this up! One high level feedback i have is we try to use utility functions + simple objects instead of classes, because it tends to produce small chunks of code that are easier to reuse and test. (We should probably note this decision with more context on the reasoning down somewhere). Would you be down to refactor the refactor to use a more functional approach? |
… and use functions.
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.
thank you! added some comments. High level feedback: let's try to create lots of small utils and then use them to create higher level utils. I also think it would be nice if each of the utils would live in a file with its name, and utils that belong to the same category are grouped in a folder (eg systems
, modules
, etc) with an index.ts
file to import them from there.
packages/cli/src/utils/modules.ts
Outdated
return configModules.filter((module) => !defaultModules.some((m) => m.name === module.name)); | ||
} | ||
|
||
export async function installModules( |
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.
should we create a installModule
util that we can use to both install the core module and the user-defined modules?
packages/cli/src/utils/modules.ts
Outdated
const { confirmations, worldContract, modules, moduleContracts, tableIds } = input; | ||
// Install modules - non-blocking for tx, await all at end | ||
const modulePromisesNew: Promise<TransactionResponse | TransactionReceipt>[] = []; | ||
for (const module of modules) { |
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.
if we have a installModule
util we can do something like
const modulePromises = modules.map(installModule);
await Promise.all(modulePromises);
packages/cli/src/utils/systems.ts
Outdated
functionArgs: string; | ||
} | ||
|
||
export async function registerSystems( |
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.
same here, feels like it would be nice to have a small registerSystem
and registerFunctionSelector
util and then use it to create a small registerSystems
util
686bea0
to
c0c0542
Compare
c0c0542
to
753e27f
Compare
753e27f
to
aa5c711
Compare
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.
So much cleaner! And can't wait for the viem refactor. Added a couple nits and will push a commit to resolve them shortly.
import { loadFunctionSignatures, toFunctionSelector } from "./utils"; | ||
import { CallData } from "../utils/types"; | ||
|
||
export function registerFunctionCalls(input: { |
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.
should we call this getRegisterFunctionSelector
to make it consistent with the other function names? Or could even rename all to get<MethodName>CallData
to make it extra clear (i was surprised for a second that this function doesn't actually register
yet but just prepares the call by returning the calldata)
packages/cli/src/utils/deploy.ts
Outdated
const schemaTypes = Object.values(schema).map((abiOrUserType) => { | ||
const { schemaType } = resolveAbiOrUserType(abiOrUserType, mudConfig); | ||
return schemaType; | ||
// Deploy all contracts - World, Core, Systems, Module. Non-blocking. |
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.
// Deploy all contracts - World, Core, Systems, Module. Non-blocking. | |
// Deploy the World contract |
packages/cli/src/utils/deploy.ts
Outdated
const txConfig = { | ||
...txParams, | ||
signer, | ||
debug: !!debug, |
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.
debug: !!debug, | |
debug: Boolean(debug), |
import { ContractCode } from "../utils/types"; | ||
|
||
// These modules are always deployed | ||
export const defaultModules: ContractCode[] = [ |
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.
for consistency with the other variable names
export const defaultModules: ContractCode[] = [ | |
export const defaultModuleContracts: ContractCode[] = [ |
Initial refactor of cli deploy script. Should make it easier to do follow up work - using Viem and create2 deployments