Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: monorepo package structure #5944

Draft
wants to merge 13 commits into
base: main
Choose a base branch
from

Conversation

briangregoryholmes
Copy link
Contributor

@briangregoryholmes briangregoryholmes commented Oct 19, 2024

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.

@briangregoryholmes briangregoryholmes self-assigned this Oct 19, 2024
@briangregoryholmes briangregoryholmes changed the title monorepo package structure chore: monorepo package structure Oct 19, 2024
@briangregoryholmes briangregoryholmes marked this pull request as draft October 20, 2024 20:01
@lovincyrus
Copy link
Contributor

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

@ericpgreen2
Copy link
Contributor

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?

@begelundmuller
Copy link
Contributor

Just for inspiration, two other projects with a Go backend and SPA frontend are:

@briangregoryholmes briangregoryholmes marked this pull request as draft November 25, 2024 17:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants