feat: add gen-deploy cli to generate deploy.json

[yoyoismee]

added mud gen-deploy cli

generate deploy.json from files

param

• components, path to components. [default to src/components]
• systems, path to systems. [default to src/systems]
• outdir, path for output. [default to deploy.json]

specification

• list all files in "components" as components
• list all files in "systems" as systems and assign write access to any imported components

files change

• added packages/cli/src/commands/gen-deploy.ts

[dk1a]

Btw this would include components that the system doesn't actually write to, not that I have a better solution in mind

[ludns]

Regex the set function?

[dk1a]

Regex the set function?

That was my 1st thought actually, but set is called on the variable, which can have any name. And even if you account for that, a library may have some func which uses set, but the system doesnt use that func.
I've been trying some stuff with solidity-parser, but it's not rly gonna help here (imports make things very complicated)

[yoyoismee]

I can think of 2 ways.

• try find calls in systems that hit any non-view/pure function on components. (might be hard tho)
• add warning that this function might add more write access than actually required. user might wanna remove some manually

[dk1a]

• For 1 you'd need to write some complicated parsing, imo not worth it for this little utility
• I like 2, would prefer it for my project compared to filling writeAccess manually from scratch

Another option I could suggest: parse e.g. @custom:ecsc TestComponent; but neither forge inspect, nor solidity-parser can do that. So I guess you'd need solc's devdoc json output. Seems complicated, but still way easier than writing a function parser.

[yoyoismee]

added warning msg :)

[dk1a]

Just fyi #309 kinda breaks this. Not asking to change anything yet, #309 is a draft and its particular features are optional anyways

[alvrs]

As discussed above this solution generates a deploy.json that gives more write access than necessary (eg. reading from a component will cause it to be added to the system's write access list). This script might still be useful for some, but to be included in MUD's default CLI we have to find a solution that generates a precise deploy.json. (Note: if you don't care about giving too many permissions, you can already put "*" into the deploy.json's write access list. Not a recommended practice of course.) Adding some conventions might help, adding "subsystems" as recommended way of splitting logic instead of libraries might help (see discussion in #327). I'll close this PR for now until we have a better foundation to autogenerate deploy.json.