build: consistent build/clean scripts

[holic]

Fixes #615

This will help us create a dependency graph of scripts, better caching, etc. (See #620)

The format I took with these build steps is to keep them focused on their output (e.g. build:js is for TS -> JS). These are also in execution order.

• build:go runs golang build steps
• build:protobuf runs codegen for protobuf
• build:mud runs mud-specific codegen
  • eventually runs mud codegen but for now is tablegen && worldgen && tsgen (see Move tablegen to Store and worldgen to World to resolve circular dependencies #616)
• build:abi runs forge build --extra-output-files abi --out abi --skip test script for abi files to be used by typechain
  • this is separate from a regular forge build in that it 1) also generates abi files, for better imports 2) outputs to a separate directory (for easier typechain targeting) and 3) skips generating files for tests/scripts to avoid cluttering typechain
• build:typechain runs typechain to generate typed ethers contracts/interfaces
• build:wasm runs asc (just for noise package)
• build:js runs tsup or rollup (see Consolidate JS build tooling #612)

Each build:* script also has a corresponding clean:* script, where applicable. Each package also has a corresponding build and clean that is a combo of any of the above (depending on what the package is doing). I expect build will only be run locally, and nx will use the steps themselves (to resolve dependent steps and run in parallel) (see #620)

Some other things to note:

• I moved one-off scripts (store's tightcoder, cli's test tables) out of the build pipeline, since they should only be run on an as-needed basis. These should be validated as up-to-date by a future lint step (like we do for gas reports).
• clean:abi uses rimraf abi instead of forge clean because the output directory is separate from the one configured by foundry.toml (used by tests, scripts)

---

TODO:

• packages
  • root package
  • cli
  • common-codegen
  • config
  • create-mud
  • ecs-browser
  • network
  • noise
  • phaserx
  • react
  • recs
  • schema-type
  • solecs
  • std-client
  • std-contracts
  • store
  • utils
  • world
  • docs
• fix circular dependencies (Move tablegen to Store and worldgen to World to resolve circular dependencies #616) to fix build
• after circ deps fix, update ../cli/dist/mud.js to mud with proper dep
  • if we still can't, may need to add back in chmod +x step
• update templates to match?
• move store's custom codegen into a one-off script and out of the build/test pipeline?
• do we need a build:forge for general building of solidity (i.e. tests, scripts) or let it get handled by e.g. forge test? do we need a clean:forge for out dir?
• rethink prepack/postpack so that pack failures don't leave bad files around, or remove the need for it entirely
• output typechain to ./typechain instead of default ./types/ethers-contracts?
• do solecs, std-contracts still need to do the out -> exports.txt -> abi conversion (prev dist task)?
• can we combine build:codegen and build:mudcodegen steps? I mostly separated because 1) some mud codegen depended on local cli to be build (thus diff dep tree) and 2) to separate from other types of codegen (e.g. typechain), maybe we move it all into a build:mud step?
• std-client can't clean up its mud definitions because it has a .test-d.ts in the same dir, consider relocating?
• remove build:abi step from schema-type? not currently in use
• consider foundry profiles for abi output vs regular out
  • these are separated because tests/scripts need the full compiled output and abi output only builds what is needed to export abis for downstream use
• make sure docs are not part of the build pipeline

[holic]

I changed this so I could move codegen.mts to codegen.ts and align this with the rest of our packages. I ran templates/minimal with this and it seemed to work just fine.

[holic]

This looked more like a one-off script so I moved it out of the build path (doesn't need to be regenerated each time and is expected to be run locally and changes committed).

[dk1a]

I agree, though it's easy to forget to run this (and this one changes often, as it's meant to test any changes to tablegen), which is why it was part of test, even though it doesn't really fit there too well.
If not part of test, it would be nice to have it somewhere else in CI at least

[holic]

added back into test script for now, will refactor in a follow up as part of #637

[holic]

This looked more like a one-off script so I moved it out of the build path (doesn't need to be regenerated each time and is expected to be run locally and changes committed).

[dk1a]

this doesn't really change/matter, but if we have some localgen script for generate-test-tables, tightcoder could also use it

[holic]

I'm planning to come back to this in #637

[holic]

I moved this out for now to avoid running build on docs when it doesn't depend on anything in the workspace.

Instead, we may want to treat this as a separate app and adjust our docs scripts throughout to generate files into this docs/.

[holic]

😭 Still need CLI here, but at least this isn't in the build path. I tried to add CLI as a dep, but that creates circular deps again. I also tried to add CLI as a dep in the root package, but there are no bins to link when it attempts to install from the workspace.

We could use whatever npm version is published, but that seems not ideal if we ever want to test changes to the gas report and want to use the local/workspace version.

We could also move the gas report out to common?

[dk1a]

the tablegen treatment for gas-report would make sense imo, except yeah it'd go to common rather than store/world. And cli just gets a wrapper over the imported script

[holic]

added an issue to track this here: #667

[holic]

Ready for review! I left a few non-blocking TODOs undone, so we can talk about em and decide if we should create follow up issues/PRs.

In terms of the build scripts defined above (and in this PR), is it worth adding a little CI script to validate that no new types of build:* scripts are added (without also extending the CI check)? This would at least make it a little more clear about the intent behind these.

[dk1a]

lgtm, though I would prefer to not put off automating generate-test-tables in some way as it changes too often and cli's tests rely on it (making it part of the build/test pipeline again temporarily would be easiest I guess)

[holic]

I’m good with moving the test tables codegen step back to test for now. Planning to follow up this PR with some refactoring for test/lint scripts. Will pick this back up next week!