chore: monorepo package structure
This PR proposes migrating our shared code structure to follow a more traditional monorepo organization. This essentially follows the guidelines from Turborepo, though this PR does not go so far as to actually use it. See Orval for a codebase that uses Turbo.
Namely, there is a new top level packages folder that houses isolated modules of shared/reusable code. Each of these will have their own dependencies, scripts, versions, test suites and will import from each other as you would import from any other package. This PR begins this process by migrating some web-common code to three packages: utils, events and actions.
I think there are number of benefits to this structure (and Turbo), though I would be lying if I said I wasn't mostly motivated by shortening our exceedingly long import paths. π€·
A follow up PR would move our web-local, web-admin and web-auth apps into an apps folder, at which point I think we should rename them to developer, cloud and auth.
This is an open discussion, but I anticipate creating the following additional packages based on our existing code: ui, state, formatting, query, icons, time, features, metrics and other packages for shared configuration.
This PR also upgrades eslint to v9.
I think there are number of benefits to this structure (and Turbo), though I would be lying if I said I wasn't mostly motivated by shortening our exceedingly long import paths. π€·
Oooh. Thanks for taking the first stab at this! We can start with something like this.
/rill
βββ admin
βββ docs
βββ proto
βββ runtime
βββ scripts
βββ packages
β βββ ui
β βββ states
β βββ constants
β βββ utils
β β βββ number-formatting
β βββ icons
βββ apps
β βββ cli
β βββ web
β β βββ admin
β β βββ auth
β β βββ local
β β βββ common
References https://github.com/vercel/turborepo/tree/main/examples/with-svelte https://github.com/orval-labs/orval/tree/master/samples/svelte-query/basic https://github.com/shadcn-ui/ui https://github.com/calcom/cal.com
I like the idea of using Turbo & I can see the benefit of creating smaller packages to improve its ability to cache.
One reservation I have is that if we nest admin, auth, local directories under apps, then I feel like the Application and Platform directory structures would be asymmetrical βΒ since admin and runtime are at the top-level, not nested under a directory like platform or services. Or would you propose a re-shuffling of those directories too?
Just for inspiration, two other projects with a Go backend and SPA frontend are:
- https://github.com/grafana/grafana
- https://github.com/sourcegraph/sourcegraph-public-snapshot (they went private recently, this is a snapshot)