Move @wavs/solidity npm package here

[dakom]

Should include everything from https://github.com/Lay3rLabs/WAVS/tree/main/contracts/solidity so that WAVS merely needs to import the required interfaces

[ethanfrey]

There are some open questions on how to distribute these contracts best. Possibilities seem to be:

• npm package
• git submodules
• cargo package (with alloy bindings)?

We should come to agreement on the way to publish before packaging stuff. I would lean toward whatever helps the end user the most, and defer to @Reecepbcups for info on what the users want. We can figure how to use stuff internally even if it isn't ideal, but want to prioritize making onboarding easy.

[Reecepbcups]

npm package is the most ideal but not required. Can hack gitsubmodule like functionality in package.json upstream like we have to do for forge. Just a depth of 1 clone

  "dependencies": {
    "forge-std": "github:foundry-rs/forge-std#v1.9.6",
    "@wavs/solidity": "^0.3.0",
  }

So long as I can do something like either of these we're good. 🚀

[ethanfrey]

Question: @Reecepbcups you use the package.json there for building/testing the ServiceHandler contracts? Or for frontend code?

Just trying to figure out best practices for package management and where it is consumed. Cuz I insist using git submodules is only a hack for languages without a proper package manager (looking at you C) and modern languages usually have a better, though language-specific, method. So knowing what tools are consuming it is helpful to shape how to distribute

[dakom]

fwiw foundry doesn't really want submodules either, they just don't know what they want yet (foundry-rs/foundry#2618)

[Reecepbcups]

I use it for building/testing the ServiceHandler contracts. I don't do any front-end work. I assume it would be the same for that though.

[ethanfrey]

Building testing the ServiceHandler via forge? Or which tool?

Could you link the lines here? The point here is to make life as easy as possible for the template so I’d love to review the whole workflow from perspective of the template

[Reecepbcups]

https://github.com/Lay3rLabs/wavs-foundry-template/blob/main/src/contracts/WavsSubmit.sol#L4-L8

where "@wavs/interfaces/IWavsServiceHandler.sol"; is @wavs/=node_modules/@wavs/solidity remapping
https://github.com/Lay3rLabs/wavs-foundry-template/blob/main/remappings.txt#L2C1-L2C35

So the flow is

npm i # downloads npm package for the @wavs/solidity

# https://github.com/Lay3rLabs/wavs-foundry-template/tree/main/src/contracts
forge build # builds the Simple Submit & Trigger contract's

# depends on the contracts/WavsTrigger.sol
# https://github.com/Lay3rLabs/wavs-foundry-template/blob/main/test/unit/WavsTrigger.t.sol
forge test

Then it is the standard flow after that for components and upload/register.