[Git] Split dapp from packages

[bitbeckers]

Describe the feature you'd like to request

The monorepo currently has all packages in the same place, but this has turned into technical debt.

• The dapp is independent of the SDK and contract packages, but is the first indicator of breaking changes in those dependencies
• The SDK depends on the contracts packags and the graph package
• The clean way of validating the SDK with the app is getting it from NPM, leaving local package availability out of scope

Describe the solution you'd like

Fork the monorepo into application and packages:

Application:

• dapp
• Defender
• CORS proxy
• OSO

Packages:

• Contracts
• Graph
• SDK

This setup separates concerns, CI/CD flows and dependencies.

Describe alternatives you've considered

Leaving the monorepo as is. In the current itteration, that means having a workspace with ignored packages. This pattern can be improved.

[ryscheng]

Discount my opinion, since at this current point in time, you guys have been more active than me in this repo

Just wanted to share my personal experience with a multi-repo setup and why I moved things to a monorepo at the time: When we had the multi-repo setup previously, it was very common for changes in the contract/SDK/libraries to break functionality downstream in the Dapp (often times it was myself making those breaking changes). The first point @bitbeckers mentioned: The dapp is independent of the SDK and contract packages, but is the first indicator of breaking changes in those dependencies, I see as a feature rather than a bug. If someone makes a change to the SDK that breaks downstream functionality, it's incredibly useful to be able to detect and fix it right away in a single PR/CI run. In theory with 100% testing coverage in every single repo and well-defined interface, this shouldn't be an issue, but IMO reality never meets that. Interfaces can and should change as you iterate. Sometimes the breakage occurs due to an untested pathway. Sometimes it occurs due to tweaks in the config (e.g. compiler/bundling). Keeping things in a monorepo that runs integration tests ensures that no matter where changes are made, it'll catch when things break. Debugging across repos can be and time-consuming and costly in terms of man-power.

I'll caveat of course that plenty of organizations use a multi-repo setup just fine, and I have no desire to bikeshed this point. Often times it's more of a decision of personal preference rather than a hard need. If devs prefer a multi-repo setup, I'm cool with whatever. I acknowledge that there are trade-offs here. In either case, as bitbeckers mentioned, we should have a test or process that ensures NPM is up to date.

And more of a minor point - in GitHub you cannot star an organization, you can only star repos. Stars are a stupid impact indicator, yet some people do rely on it, so we all still have a perverse incentive to maximize the stars we get. One reason some projects stick to a monorepo, is to create a single place to star/watch/follow, rather than spread stars out across repos.