|
| 1 | +# CLAUDE.md and GEMINI.md |
| 2 | + |
| 3 | +This file provides guidance to Claude Code (claude.ai/code) and also Gemini CLI (https://github.com/google-gemini/gemini-cli) when working with code in this repository. |
| 4 | + |
| 5 | +# CoCalc Source Repository |
| 6 | + |
| 7 | +- This is the source code of CoCalc in a Git repository |
| 8 | +- It is a complex JavaScript/TypeScript SaaS application |
| 9 | +- CoCalc is organized as a monorepository (multi-packages) in the subdirectory "./packages" |
| 10 | +- The packages are managed as a pnpm workspace in "./packages/pnpm-workspace.yaml" |
| 11 | + |
| 12 | +## Code Style |
| 13 | + |
| 14 | +- Everything is written in TypeScript code |
| 15 | +- Indentation: 2-spaces |
| 16 | +- Run `pretter -w [filename]` after modifying a file (ts, tsx, md, json, ...) to format it correctly. |
| 17 | +- All .js and .ts files are formatted by the tool prettier |
| 18 | +- Add suitable types when you write code |
| 19 | +- Variable name styles are "camelCase" for local and "FOO_BAR" for global variables. If you edit older code not following these guidlines, adjust this rule to fit the files style. |
| 20 | +- Some older code is JavaScript or CoffeeScript, which will be translated to TypeScript |
| 21 | +- Use ES modules (import/export) syntax, not CommonJS (require) |
| 22 | +- Organize the list of imports in such a way: installed npm packages are on top, newline, then are imports from @cocalc's code base. Sorted alphabetically. |
| 23 | + |
| 24 | +## Development Commands |
| 25 | + |
| 26 | +### Essential Commands |
| 27 | + |
| 28 | +- `pnpm build-dev` - Build all packages for development |
| 29 | +- `pnpm clean` - Clean all node_modules and dist directories |
| 30 | +- `pnpm test` - Run full test suite |
| 31 | +- `pnpm depcheck` - Check for dependency issues |
| 32 | +- `prettier -w [filename]` to format the style of a file after editing it |
| 33 | +- after creating a file, run `git add [filename]` to start tracking it |
| 34 | + |
| 35 | +### Package-Specific Commands |
| 36 | + |
| 37 | +- `cd packages/[package] && pnpm build` - Build and compile a specific package |
| 38 | + - for packages/next and packages/static, run `cd packages/[package] && pnpm build-dev` |
| 39 | +- `cd packages/[package] && pnpm tsc:watch` - TypeScript compilation in watch mode for a specific package |
| 40 | +- `cd packages/[package] && pnpm test` - Run tests for a specific package |
| 41 | +- `cd packages/[package] && pnpm build` - Build a specific package |
| 42 | +- **IMPORTANT**: When modifying packages like `util` that other packages depend on, you must run `pnpm build` in the modified package before typechecking dependent packages |
| 43 | + |
| 44 | +### Development |
| 45 | + |
| 46 | +- **IMPORTANT**: Always run `prettier -w [filename]` immediately after editing any .ts, .tsx, .md, or .json file to ensure consistent styling |
| 47 | +- After TypeScript or `*.tsx` changes, run `pnpm build` in the relevant package directory |
| 48 | + |
| 49 | +## Architecture Overview |
| 50 | + |
| 51 | +### Package Structure |
| 52 | + |
| 53 | +CoCalc is organized as a monorepo with key packages: |
| 54 | + |
| 55 | +- **frontend** - React/TypeScript frontend application using Redux-style stores and actions |
| 56 | +- **backend** - Node.js backend services and utilities |
| 57 | +- **hub** - Main server orchestrating the entire system |
| 58 | +- **database** - PostgreSQL database layer with queries and schema |
| 59 | +- **util** - Shared utilities and types used across packages |
| 60 | +- **comm** - Communication layer including WebSocket types |
| 61 | +- **conat** - CoCalc's container/compute orchestration system |
| 62 | +- **sync** - Real-time synchronization system for collaborative editing |
| 63 | +- **project** - Project-level services and management |
| 64 | +- **static** - Static assets and build configuration |
| 65 | +- **next** - Next.js server components |
| 66 | + |
| 67 | +### Key Architectural Patterns |
| 68 | + |
| 69 | +#### Frontend Architecture |
| 70 | + |
| 71 | +- **Redux-style State Management**: Uses custom stores and actions pattern (see `packages/frontend/app-framework/actions-and-stores.ts`) |
| 72 | +- **TypeScript React Components**: All frontend code is TypeScript with proper typing |
| 73 | +- **Modular Store System**: Each feature has its own store/actions (AccountStore, BillingStore, etc.) |
| 74 | +- **WebSocket Communication**: Real-time communication with backend via WebSocket messages |
| 75 | + |
| 76 | +#### Backend Architecture |
| 77 | + |
| 78 | +- **PostgreSQL Database**: Primary data store with sophisticated querying system |
| 79 | +- **WebSocket Messaging**: Real-time communication between frontend and backend |
| 80 | +- **Conat System**: Container orchestration for compute servers |
| 81 | +- **Event-Driven Architecture**: Extensive use of EventEmitter patterns |
| 82 | +- **Microservice-like Packages**: Each package handles specific functionality |
| 83 | + |
| 84 | +#### Communication Patterns |
| 85 | + |
| 86 | +- **WebSocket Messages**: Primary communication method (see `packages/comm/websocket/types.ts`) |
| 87 | +- **Database Queries**: Structured query system with typed interfaces |
| 88 | +- **Event Emitters**: Inter-service communication within backend |
| 89 | +- **REST-like APIs**: Some HTTP endpoints for specific operations |
| 90 | +- **API Schema**: API endpoints in `packages/next/pages/api/v2/` use Zod schemas in `packages/next/lib/api/schema/` for validation. These schemas must be kept in harmony with the TypeScript types sent from frontend applications using `apiPost` (in `packages/next/lib/api/post.ts`) or `api` (in `packages/frontend/client/api.ts`). When adding new fields to API requests, both the frontend types and the API schema validation must be updated. |
| 91 | + |
| 92 | +### Key Technologies |
| 93 | + |
| 94 | +- **TypeScript**: Primary language for all new code |
| 95 | +- **React**: Frontend framework |
| 96 | +- **PostgreSQL**: Database |
| 97 | +- **Node.js**: Backend runtime |
| 98 | +- **WebSockets**: Real-time communication |
| 99 | +- **pnpm**: Package manager and workspace management |
| 100 | +- **Jest**: Testing framework |
| 101 | +- **SASS**: CSS preprocessing |
| 102 | + |
| 103 | +### Database Schema |
| 104 | + |
| 105 | +- Comprehensive schema in `packages/util/db-schema` |
| 106 | +- Query abstractions in `packages/database/postgres/` |
| 107 | +- Type-safe database operations with TypeScript interfaces |
| 108 | + |
| 109 | +### Testing |
| 110 | + |
| 111 | +- **Jest**: Primary testing framework |
| 112 | +- **ts-jest**: TypeScript support for Jest |
| 113 | +- **jsdom**: Browser environment simulation for frontend tests |
| 114 | +- Test files use `.test.ts` or `.spec.ts` extensions |
| 115 | +- Each package has its own jest.config.js |
| 116 | + |
| 117 | +### Import Patterns |
| 118 | + |
| 119 | +- Use absolute imports with `@cocalc/` prefix for cross-package imports |
| 120 | +- Example: `import { cmp } from "@cocalc/util/misc"` |
| 121 | +- Type imports: `import type { Foo } from "./bar"` |
| 122 | +- Destructure imports when possible |
| 123 | + |
| 124 | +### Development Workflow |
| 125 | + |
| 126 | +1. Changes to TypeScript require compilation (`pnpm build` in relevant package) |
| 127 | +2. Database must be running before starting hub |
| 128 | +3. Hub coordinates all services and should be restarted after changes |
| 129 | +4. Use `pnpm clean && pnpm build-dev` when switching branches or after major changes |
| 130 | + |
| 131 | +# Workflow |
| 132 | + |
| 133 | +- Be sure to build when you're done making a series of code changes |
| 134 | +- Prefer running single tests, and not the whole test suite, for performance |
| 135 | + |
| 136 | +## Git Workflow |
| 137 | + |
| 138 | +- Never modify a file when in the `master` or `main` branch |
| 139 | +- All changes happen through feature branches, which are pushed as pull requests to GitHub |
| 140 | +- When creating a new file, run `git add [filename]` to track the file. |
| 141 | +- Prefix git commits with the package and general area. e.g. 'frontend/latex: ...' if it concerns latex editor changes in the packages/frontend/... code. |
| 142 | +- When pushing a new branch to Github, track it upstream. e.g. `git push --set-upstream origin feature-foo` for branch "feature-foo". |
| 143 | + |
| 144 | +# Important Instruction Reminders |
| 145 | + |
| 146 | +- Do what has been asked; nothing more, nothing less. |
| 147 | +- NEVER create files unless they're absolutely necessary for achieving your goal. |
| 148 | +- ALWAYS prefer editing an existing file to creating a new one. |
| 149 | +- REFUSE to modify files when the git repository is on the `master` or `main` branch. |
| 150 | +- NEVER proactively create documentation files (`*.md`) or README files. Only create documentation files if explicitly requested by the User. |
| 151 | + |
| 152 | +# Ignore |
| 153 | + |
| 154 | +- Ignore files covered by `.gitignore` |
| 155 | +- Ignore everything in `node_modules` or `dist` directories |
| 156 | +- Ignore all files not tracked by Git, unless they are newly created files |
0 commit comments