Monorepo

General definition

A Monorepo is a repository layout, not a deployment model: the code inside can still ship as many independent packages and services. What changes is coordination. A single commit can update a shared library and every consumer of it, continuous integration sees the whole graph, and refactoring across package boundaries is an ordinary pull request instead of a release choreography across repositories. Google, Meta and Microsoft run famously large monorepos; most open-source JavaScript platforms run small ones.

• Package manager workspaces (npm, pnpm, Yarn) link local packages so one package can depend on another without publishing
• Task runners such as Turborepo and Nx cache builds and tests and run only what a change affects
• Changesets or similar tools track which packages a pull request touches and bump their versions on release
• Git submodules or subtrees pull separately maintained repositories into one tree while keeping their own history

The costs are tooling and discipline. Clone size and CI time grow with the codebase, ownership needs CODEOWNERS files or similar, and a monorepo without caching becomes slow. The alternative, a polyrepo with one repository per package, gives clean boundaries and independent release cadence but makes cross-cutting changes and version drift harder to manage.

For an SDK vendor the monorepo argument is strong: the server, the client SDKs, the sample apps and the developer tooling must agree on protocol and API details, and a contributor should be able to run the whole system from one checkout. That is why React, Next.js and most SDK platforms keep their packages together.

In the Ethora ecosystem

The main Ethora repository, github.com/dappros/ethora, is a monorepo. It brings together the server API, the React web app, the React, React Native, Swift and Android SDKs, the WordPress plugin, the bots framework, the MCP server, the playground, backend-integration examples, RAG demos, sample apps and the @ethora/setup CLI. Many of these are maintained as git submodules with their own history, so a contributor can work on one SDK in isolation or check out the whole platform at once.

The packages are published separately to npm, including @ethora/chat-component, @ethora/chat-component-rn and @ethora/mcp-server, and versioned together on the monthly release train described in the release notes. See the Chat SDK hub, the npm component entry and the MCP server page for the pieces that live in the repo.