feat(cli): add initialization libs to deploy

[dk1a]

deploy.json already has "init" for systems.
But systems are contracts. Scripts are best run through libraries.

Example:
An expensive addItem function, which adds a game item prototype with all its properties. Say it costs 1mil gas per item. I have an initializer which adds 100 of those. 100mil gas exceeds the limit.

• If the 100 adds are in a system contract, it will revert. And making a bunch of wrapper init systems is a really bad idea.
• If the 100 adds are in a library, forge script can at least split it into several transactions. But also the real contract calls (component sets) use only a small portion of all that gas.

(this is a simplified edge case, my real use case is unfinished and more convoluted, but similar enough, e.g. InitEquipmentAffixSystem uses way more than the transaction gas limit)

I tested that it minimally works via a slightly modified emojimon, if you wanna just clone it.

Some concerns:

• libs may not be the best name, open to suggestions
• The whole idea of modifying LibDeploy may be a bit too hardcodey. Maybe having a user-controllable Deploy.sol would be best. But that's way beyond the scope of this simple PR. (feat(cli): allow arbitrary project structure for LibDeploy and system types #309 kinda goes in that direction a bit, making scripts more local)

[frolic]

Love this idea.

I wonder if it's worth adding a scripts directory (and follow the foundry *.s.sol naming scheme) to keep the initialization scripts/logic separate from the long-running logic (libs).

[dk1a]

I wonder if it's worth adding a scripts directory (and follow the foundry *.s.sol naming scheme) to keep the initialization scripts/logic separate from the long-running logic (libs).

scripts is kinda like src, test, out, it should exist in the root (according to the defaults of foundry book, and my preference).
Something like Deploy.sol is a script (#311 is related), and should probably be Deploy.s.sol.

But I would prefer libraries that are used by scripts to still be inside src. They can be however kept in a separate dir from the other libs. This is mostly because #309 needs libs in src, but also allows them to be in arbitrary subfolders (for example src/init for init libs).

[alvrs]

Great addition!

[frolic]

Just so I understand, this is meant to replace the current pattern of InitSystems, right?

Can we add docs for this? Maybe here: https://mud.dev/guides/getting_started/#deployment

[dk1a]

Just so I understand, this is meant to replace the current pattern of InitSystems, right?

Yep

Can we add docs for this? Maybe here: https://mud.dev/guides/getting_started/#deployment

I'll make a PR