Repo restructure

[andrew-fleming]

Since we now have quite a few modules, I think it's time to consider how the repo should be structured and what releases will look like.

I propose three ideas and the tradeoffs as I see them:

1. Separate contract packages

contracts/
      ├──token/
         ├──package.json
         ├──tsconfig.build.json
         ├──tsconfig.json
         ├──vitest.config.ts
         └──src/
            ├──FungibleToken.compact
            ├──witnesses/
                 └──FungibleTokenWitnesses.ts
            └──test/
                 ├──FungibleToken.test.ts
                 ├──mocks/
                      └──MockFungibleToken.ts
                 └──simulators/
                      └──FungibleTokenSimulator.ts

This basically follows the current structure with the difference that we consolidate modules into subpackages:

access/
   ├──accessControl/
   └──ownable/

Pros:

• Easy refactor
• Easy to filter with turbo
• Smaller packages for users. If you just want to use Ownable, you don't need to install everything

Cons:

• Excess boilerplate
• No transitive deps -> Users will have to manually declare internal deps (i.e. Initializable)

2. Single contracts package with colocated tests

contracts/
   ├──package.json
   ├──tsconfig.build.json
   ├──tsconfig.json
   ├──vitest.config.ts
   └──src/
       ├──token/
            ├──FungibleToken.compact
            ├──witnesses/
                 └──FungibleTokenWitnesses.ts
            └──test/
                 ├──FungibleToken.test.ts
                 ├──mocks/
                      └──MockFungibleToken.ts
                 └──simulators/
                      └──FungibleTokenSimulator.ts

Pros:

• Support for transitive deps
• Easy to install
• Less boilerplate for new modules
• Some prefer colocated tests

Cons:

• Bigger package => more bloat for users
• Difficult to filter for compiling, building, and testing
  • We need to get creative => support with compact package, scripting, etc

3. Single contracts package with external tests

contracts/
   ├──package.json
   ├──tsconfig.build.json
   ├──tsconfig.json
   └──src/
      ├──token/
          ├──FungibleToken.compact
          └──witnesses/
              └──FungibleTokenWitnesses.ts
test/
  ├──token/
      ├──FungibleToken.test.ts
      ├──mocks/
          └──MockFungibleToken.ts
      └──simulators/
          └──FungibleTokenSimulator.ts

vitest.config.ts

Pros:

• Same as #2
• IMO cleaner and more discoverable than #2

Cons:

• Same as #2

*Side note: We could create a common directory in test/ for sim and mocks to make them shareable for more complex features. IMO that's not necessary now though

---

Obviously, there are other structures we can consider. Perhaps, there's a hybrid structure that supports the transitive deps issue and gives users the freedom to only install a single package (we offer the all-inclusive openzeppelin package as well as individual subpackages in Contracts for Cairo).

For now, I think #3 is overall the best route to take while the repo is small and still experimental. LMK what y'all think @emnul @0xisk

[emnul]

I agree with moving forward with option 3.

[andrew-fleming]

In a different but related matter, I also propose the following groupings for now:

contracts/src/token/
      ├──FungibleToken.compact
      ├──NonFungibleToken.compact
      └──MultiToken.compact

contracts/src/access/
      ├──AccessControl.compact
      └──Ownable.compact

contracts/src/security/
      ├──Initializable.compact
      └──Pausable.compact

contracts/src/utils/
      ├──Address.compact
      └──Utils.compact // Not sure on this bc there's just the `emptyString` circuit ATM

---

And then I eventually foresee something like this:

token

contracts/src/token/transparent
      ├──FungibleToken.compact
      ├──NonFungibleToken.compact
      └──MultiToken.compact

contracts/src/token/shielded
      ├──Z_FungibleToken.compact
      ├──Z_NonFungibleToken.compact
      └──Z_MultiToken.compact

access

contracts/src/access/transparent/
      ├──AccessControl.compact
      └──Ownable.compact

contracts/src/access/shielded/
      ├──Z_AccessControl.compact
      └──Z_Ownable.compact

Maybe it's better for shielded to be the default and non-shielded modules should instead have the prefix T i.e. T_FungibleToken? Or maybe both T_ and Z_?