wip system deploys

[frolic]

We're exploring what it might look like for package-exportable representation of MUD resources, where the current MUD config is only a partial representation since systems are defined by what's on the filesystem. This adds an intermediate build step and JSON representation of those systems so that we can then export a complete view of what's to be deployed.

TODO

• extract and include system functions to register onchain
• translate accessList to a set of addresses + system IDs? (could still be done by deployer but might be nice to move here)
• update deployer to use this new JSON file

[changeset-bot]

⚠️ No Changeset found

Latest commit: fbdc797

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[frolic]

a thing I fiddled with in 5c7ba76 is a "pure" representation of a given system and all its dependent bytecode, where references to public libs in the bytecode are replaced by the library bytecode that the deployer would "unwind" and deploy deepest first, swap with address, then continue outward until the system is deployed

this is ~double the filesize as the current state where we now reference "deployables" and have a top-level "deployables" object with bytecode of libraries

even though it's larger, I still like the former because it's more "pure" and easier to merge without naming conflicts across projects ("deployable" source file structures and contracts may be similarly named within a namespace), but hard to each opton until we get to the step where we start combine configs/manifests for the entire world deploy

[frolic]

this is almost a representation of the things needed to deploy but aren't represented by config output, just missing system functions to be registered (wouldn't be too hard to add)

then would need to bake this new JSON into deployer and figure out how to build a metadata package with this new format + bake in as a default during world deploy

but worried about the number of unknowns still here when we get to the config combining step that I am thinking of pausing this work for now to just unblock metadata via regular world module then revisit this later

[frolic]

sort of continuing this work in #3050

closing this for now