feat(cli): declarative deployment

[holic]

• Deploy step now takes in a fully-resolved config and an optional world address, inspects the world, and does the minimal set of operations necessary to bring the world in alignment with the config.
  • This deploy function attempts to look at the world from the deploy block number to the block number when the function was called, to keep all the world values in alignment (since they may be reading from the chain at different times/blocks during the deploy process). This may cause issues with certain RPCs that limit block ranges on read queries.
  • This isn't "fully" declarative and could later be improved by separating the "plan" step from the "apply" step (ala terraform), but I didn't want to spend too much time on this. The bones are there to move in this direction though!
  • This doesn't have a "generate MUD config from world" yet, but again, the bones are there to build off of.
  • This doesn't check namespace ownership/access yet and will throw an error or revert if we attempt an operation on a namespace we don't have access to. This could be improved by doing some checks during the "plan" step. This is now included.
• dev-contracts CLI command is simplified to 1) watch files that would affect the world and 2) rebuild/redeploy everything. Since the deploy step is much smarter and only does the minimal work necessary, I am hoping the speed gains here can justify re-running build for now (to keep the logic simpler). Worth a refactor in the future when we have more time to spend on making this great.

[changeset-bot]

🦋 Changeset detected

Latest commit: 339ffd1

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

This PR includes changesets to release 30 packages

Name	Type
@latticexyz/cli	Major
@latticexyz/world	Major
@latticexyz/dev-tools	Major
@latticexyz/store-sync	Major
@latticexyz/world-modules	Major
@latticexyz/store-indexer	Major
@latticexyz/abi-ts	Major
@latticexyz/block-logs-stream	Major
@latticexyz/common	Major
@latticexyz/config	Major
create-mud	Major
@latticexyz/ecs-browser	Major
@latticexyz/faucet	Major
@latticexyz/gas-report	Major
@latticexyz/network	Major
@latticexyz/noise	Major
@latticexyz/phaserx	Major
@latticexyz/protocol-parser	Major
@latticexyz/react	Major
@latticexyz/recs	Major
@latticexyz/schema-type	Major
@latticexyz/services	Major
@latticexyz/solecs	Major
solhint-config-mud	Major
solhint-plugin-mud	Major
@latticexyz/std-client	Major
@latticexyz/std-contracts	Major
@latticexyz/store-cache	Major
@latticexyz/store	Major
@latticexyz/utils	Major

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

[holic]

cc @CrazyNorman

there's a few other TODOs for batchCall in here but I think this is one place we can add it that has meaningful impact to the deploy functionality vs. just making it faster

[CrazyNorman]

cc @CrazyNorman

there's a few other TODOs for batchCall in here but I think this is one place we can add it that has meaningful impact to the deploy functionality vs. just making it faster

Got you. So If I'm getting you right, we can use batchCall to do atomic setup, handling each system as a whole, one by one. This will make the deployment steps more modular.

[holic]

Exactly! If we for some reason fail to register a system but add access control, or vice versa, that feels like a weird state to be in. Using batchCall here should help keep the operation atomic so if one step in setting up the system fails, the entire system setup fails.

[alvrs]

i'm very excited about this! Let's 🚢