Skip to content

Work in progress #51

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.

Sign up for GitHub

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

Merged
AviPeltz merged 1 commit into from
Nov 10, 2025
Merged

Work in progress #51

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
120 changes: 119 additions & 1 deletion README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1 +1,119 @@
Avi said I need a README
# Superset

A modern monorepo for Superset - featuring a website, desktop app, docs, and blog.

## Quick Start

```bash
# Install dependencies
bun install

# Start development servers
bun dev

# Run tests
bun test
```

## Tech Stack

- **Package Manager**: Bun
- **Build System**: Turborepo
- **Database**: Drizzle ORM + Neon PostgreSQL
- **UI**: React + TailwindCSS v4 + shadcn/ui
- **Code Quality**: Biome (formatting + linting)

## Project Structure

```
apps/
├── website/ # Main website application
├── desktop/ # Electron desktop app
├── docs/ # Documentation site
└── blog/ # Blog site

packages/
├── ui/ # Shared UI components (shadcn/ui)
├── db/ # Drizzle ORM database schema
├── constants/ # Shared constants
├── models/ # Shared data models
├── scripts/ # CLI tooling
└── typescript-config/ # TypeScript configurations
```

## Development

### Common Commands

```bash
# Development
bun dev # Start all dev servers
bun test # Run tests
bun build # Build all packages

# Code Quality
bun run lint # Format + lint + fix auto-fixable issues
bun run lint:check # Check only (no changes, for CI)
bun run format # Format code only
bun run format:check # Check formatting only (CI)
bun run typecheck # Type check all packages

# Database
bun run db:push # Apply schema changes
bun run db:seed # Seed database
bun run db:migrate # Run migrations
bun run db:studio # Open Drizzle Studio

# Maintenance
bun run clean # Clean root node_modules
bun run clean:workspaces # Clean all workspace node_modules
```

### Adding UI Components

```bash
cd packages/ui
npx shadcn@latest add <component>
```

## Code Quality

This project uses Biome for formatting and linting (configured at root level):

- **Format + Lint**: `bun run lint` - Automatically fixes issues
- **Check Only**: `bun run lint:check` - Validates without changes (CI)

## Database

Schema is defined in `packages/db/src/` using Drizzle ORM.

### Migrations

1. Spin up a new Neon branch for migrations
2. Update root `.env` to point at the Neon branch
3. Modify Drizzle schema in `packages/db/src/schema`
4. Generate migration: `pnpm drizzle-kit generate --name="migration_name_snake_case"`
Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot Nov 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

Update package manager to bun for consistency.

The migration command uses pnpm, but the entire project is built on bun. Update this to use bun run for consistency across all documented commands.

-4. Generate migration: `pnpm drizzle-kit generate --name="migration_name_snake_case"`
+4. Generate migration: `bun run drizzle-kit generate --name="migration_name_snake_case"`

Verify the correct syntax for running Drizzle migrations with Bun in your project setup.

I'll verify the review comment by checking the project's package manager setup and documentation consistency.


---

🏁 Script executed:

```shell
#!/bin/bash
# Check for package manager indicators in the project root
fd -t f -e json -e lock -e yaml -e yml '(package\.json|bun\.lock|pnpm-lock|yarn\.lock|\.npmrc)' . --max-depth 1 | head -20

Length of output: 25

🏁 Script executed:

#!/bin/bash
# Extract context around README.md line 95 and search for package manager references
rg -n 'pnpm|bun run|npm run|yarn' README.md -C 2 | head -50

Length of output: 1357

🏁 Script executed:

#!/bin/bash
# Check package.json for package manager specification
if [ -f "package.json" ]; then
  echo "=== package.json exists ===" && cat package.json | head -30
fi

Length of output: 911

🏁 Script executed:

#!/bin/bash
# Search for drizzle-kit documentation in README
rg -n 'drizzle-kit|migration' README.md -i -C 3 | head -80

Length of output: 636

🏁 Script executed:

#!/bin/bash
# Check if bun.lock exists (indicates bun is used)
if [ -f "bun.lock" ]; then
  echo "bun.lock exists - project uses bun"
else
  echo "bun.lock not found"
fi

if [ -f "pnpm-lock.yaml" ]; then
  echo "pnpm-lock.yaml exists - project uses pnpm"
else
  echo "pnpm-lock.yaml not found"
fi

Length of output: 59

🏁 Script executed:

#!/bin/bash
# Count package manager command occurrences in README
echo "=== pnpm occurrences in README.md ===" && rg -c 'pnpm' README.md
echo "=== bun occurrences in README.md ===" && rg -c '\bbun\b' README.md
echo "=== npm occurrences in README.md ===" && rg -c '\bnpm\b' README.md

Length of output: 116

🌐 Web query:

What is the correct syntax for running Drizzle Kit migrations with Bun?

💡 Result:

Use Bun's bunx to run the drizzle-kit CLI, or run a migrator script with bun run.

Examples:

  • CLI (generate then apply):
    bunx drizzle-kit generate --dialect sqlite --schema ./schema.ts
    bunx drizzle-kit migrate --config=./drizzle.config.ts. [1][2]

  • Programmatic migrator (e.g. migrate.ts) and run with Bun:
    bun run migrate.ts (migrate.ts calls migrate(...) from drizzle-orm/*/migrator). [1][2]

Sources: Bun Drizzle guide and Drizzle Kit docs. [1][2]

Update package manager to bun and use correct Bun syntax for consistency.

Line 95 is the only place in README that uses pnpm; all other documented commands use bun. Additionally, the correct idiomatic syntax for Bun is bunx drizzle-kit generate, not bun run drizzle-kit generate (since there's no drizzle-kit script in package.json).

-4. Generate migration: `pnpm drizzle-kit generate --name="migration_name_snake_case"`
+4. Generate migration: `bunx drizzle-kit generate --name="migration_name_snake_case"`
🤖 Prompt for AI Agents 
In README.md around line 95, replace the pnpm command with Bun's idiomatic
invocation: change "pnpm drizzle-kit generate
--name=\"migration_name_snake_case\"" to use bunx (i.e. "bunx drizzle-kit
generate --name=\"migration_name_snake_case\"") so the README is consistent with
the rest of the document and uses Bun's correct syntax (do not use "bun run"
since there is no drizzle-kit script in package.json).


**Neon Details:**
- Org ID: `org-round-base-25422821`
- Project ID: `tiny-cherry-82420694`
Comment on lines +98 to +99
Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot Nov 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

Remove sensitive project identifiers from README.

Neon org ID and project ID should not be committed to the repository in plain text. Move these identifiers to a secure location such as .env.example, internal documentation, or a team wiki.

-**Neon Details:**
-- Org ID: `org-round-base-25422821`
-- Project ID: `tiny-cherry-82420694`
+**Neon Details:**
+See internal documentation or team wiki for Neon credentials.

Confirm whether these identifiers are public or if they should be removed from the README for security and compliance purposes.

I'll verify this review comment by examining the README.md file and researching the sensitivity of Neon identifiers.

🏁 Script executed:

#!/bin/bash
# Examine README.md around lines 98-99
if [ -f README.md ]; then
  echo "=== README.md lines 90-110 ==="
  sed -n '90,110p' README.md
  echo ""
  echo "=== Searching for org-round-base or tiny-cherry identifiers ==="
  rg -n "org-round-base|tiny-cherry" --type-add 'text:txt:md' --type text README.md || echo "No matches in README.md"
else
  echo "README.md not found"
fi

# Search entire codebase for these identifiers
echo ""
echo "=== Searching entire codebase for identifiers ==="
rg -n "org-round-base-25422821|tiny-cherry-82420694" || echo "No matches found"

Length of output: 1135

🌐 Web query:

Neon PostgreSQL org ID project ID sensitive security best practices

💡 Result:

Concise best-practices for Neon (Postgres) Organization ID / Project ID security

Quick note: Neon’s docs and IaC guides show orgId/projectId are required identifiers for creating/managing resources (Pulumi/OpenTofu examples). Treat them as low‑secrecy identifiers but still handle carefully to avoid accidental exposure or telemetry linking. [1][2]

Practical guidance

  • Classify sensitivity: treat orgId/projectId as low‑secret identifiers (useful to attackers for discovery) — avoid exposing them publicly when unnecessary. [1][2]
  • Never embed API keys or Neon credentials in front‑end/client code. Store API keys, connection URIs, and passwords only in secret stores or environment variables. [1][2]
  • Limit and scope API keys: create least‑privilege Neon API keys for CI/CD, automation, or service accounts; avoid long‑lived full‑access keys when possible. Use per‑project keys. [2]
  • Use secrets managers & CI secret features: keep NEON_API_KEY, DATABASE_URL, connection URIs, and generated tokens in Vault/AWS Secrets Manager/GCP Secret Manager/CI secret stores (don’t commit to repo). [1][2]
  • Treat connection strings and passwords as secrets: mark outputs as secret in IaC (e.g., pulumi.secret / provider sensitive outputs) so they aren’t printed to logs. [1]
  • RBAC and access control: restrict Neon console and API access to necessary team members; use organization/project permissions rather than sharing root credentials. [1][2]
  • Audit & rotate: enable/log Neon audit events where available, rotate API keys and DB passwords on a schedule or after incidents. [2]
  • Telemetry & logs hygiene: redact org.id/project.id or treat as potential PII when sending traces/metrics (filter or redaction rules); avoid leaking identifiers with user data in logs/traces. [3]
  • IaC safety: when using Pulumi/OpenTofu/Terraform, explicitly set orgId/projectId to avoid accidental resource creation in wrong orgs, and keep IaC state files and provider credentials secured. Mark sensitive outputs and do not write keys to plain state. [1][2]
  • Network & connection security: enforce TLS for DB connections, restrict allowed client IPs where supported, and use role‑based DB users with minimum privileges (separate roles for migration/app/readonly). [1][2]
  • Backups & disaster recovery: protect instant‑restore/backups access with same secrets controls; encrypt backups and restrict restore permissions to a small set of admins. [1][2]
  • CI/CD & automation best practices: use ephemeral tokens, short‑lived credentials where possible, and avoid embedding project/org ids with secrets in public logs. Use dedicated service accounts for automation. [2]

If you’d like, I can:

  • produce a short checklist you can paste into your security policy or CI pipeline, or
  • inspect a sample Neon/IaC config (sanitized) and point out exposure risks.

Sources

  • Neon Pulumi guide (orgId/projectId usage; mark outputs as secrets). [1]
  • Neon OpenTofu / provider docs (API key handling, project/resource IDs, IaC notes). [2]
  • PII/telemetry redaction guidance (org.id/project.id treated as sensitive in traces). [3]

References
[1] Neon — Manage Neon with Pulumi (orgId, secrets, mark outputs as secret).
[2] Neon — Manage Neon with OpenTofu / Terraform provider (API key usage, project/resource id formats, secret handling).
[3] PII filtering / telemetry practices (org.id and project.id redaction examples).

Remove Neon org ID and project ID from public documentation and code.

Neon org IDs and project IDs are low-secret identifiers useful to attackers for discovery and should avoid being exposed publicly when unnecessary. These identifiers are currently hardcoded in multiple files:

  • README.md (lines 98-99)
  • conductor-setup.sh (line 32)
  • AGENTS.md (line 134)

Move these to .env.example, internal documentation, or a team wiki. For runtime configuration, use environment variables instead of hardcoded values in version control.

 **Neon Details:**
-Org ID: `org-round-base-25422821`
-Project ID: `tiny-cherry-82420694`
+See internal documentation or team wiki for Neon credentials.
🤖 Prompt for AI Agents 
README.md lines 98-99: remove the hardcoded Neon org ID and project ID from the
README and replace them with a placeholder or instruction that points to an
environment variable (e.g., mention NEON_ORG_ID and NEON_PROJECT_ID) and
reference .env.example; also add/update .env.example with these keys (no real
secrets/IDs) and move any explanatory/internal details to internal docs or a
team wiki; additionally update conductor-setup.sh (line 32) and AGENTS.md (line
134) to stop using hardcoded IDs and instead read from the same environment
variables at runtime.


## Desktop App

The desktop app (`apps/desktop`) is built with Electron and features:

- Type-safe IPC communication
- Terminal management with node-pty
- Git worktree-based workspace management

See `apps/desktop/docs/TYPE_SAFE_IPC.md` for IPC documentation.

## Contributing

1. Keep diffs minimal and targeted
2. Follow existing code patterns
3. Maintain type safety (avoid `any`)
4. Co-locate components by usage
5. Run `bun run lint` before committing

For detailed architecture guidelines, see `AGENTS.md`.
Loading