Skip to content

Since the last run

Overall +6 points

drizzle-team/drizzle-orm (opens in a new tab)

A well-documented, active project with solid onboarding, but the monorepo structure and heavy dependency on external databases make local setup non-trivial for newcomers.

TypeScript★ 34,8201,851 open issuesApache License 2.0
Overall score: 78 out of 100
Holding

last scored 2026-06-15

Readiness lenses

The same repo, two ways: how ready it is for an AI coding agent, and for a human newcomer. Switch lenses to see each one's score and checks.

How ready the repo is for an AI coding agent to read, build, and operate it.

21 of 34 checks passed across 6 categories.

  • Machine Orientation

    4 checks passed3 problems found

    • mediumAgent instructions file

      AGENTS.md / CLAUDE.md is the direct, machine-read channel for entry points and conventions.

      Fix: Add an AGENTS.md naming the entry points, the build/test commands, and the house conventions.

    • lowllms.txt present

      An llms.txt is the emerging machine-orientation standard — a curated map for LLMs.

      Fix: Add an llms.txt pointing at the key docs and entry points.

    • lowArchitecture doc

      An ARCHITECTURE doc hands an agent the module map instead of making it infer one.

      Fix: Add an ARCHITECTURE.md describing the major components and how they fit.

    • README present — An agent reconstructs what the repo is and how to work in it from the README first.
    • Repository description set — The one-line description is the fastest orientation signal an agent reads.
    • Topics set — GitHub topics situate the repo's domain and stack for an agent at a glance.
    • Contribution conventions are written down — A contributor guide is where an agent learns the branch, commit, and review conventions it must follow.
  • Reproducible Setup

    4 checks passed2 problems found

    • mediumContainer or dev-container

      A Dockerfile / compose / devcontainer removes 'works on my machine' from setup.

      Fix: Add a Dockerfile, a compose file, or a .devcontainer so the environment is declared, not assumed.

    • lowDev container

      A .devcontainer gives an agent a one-command, fully-declared environment.

      Fix: Add a .devcontainer so the toolchain is declared, not assumed.

    • Lockfile committed — Without a lockfile two clones can resolve different dependency trees — the build isn't reproducible.
    • Runtime / toolchain pinned — An unpinned runtime makes an agent guess the version a clean environment needs.
    • Version pins are exact — A floating pin (a bare major, or a range) still drifts between installs.
    • Env template present — A .env.example tells an agent which configuration keys it must supply to run.
  • Code Navigability

    1 check passed1 problem found

    • mediumConventional source layout

      A recognised src/ · lib/ · app/ layout lets an agent localise code without spelunking.

      Fix: Group source under a conventional top-level directory (src/, lib/, app/, …).

    • TypeScript strict mode on — Strict typing gives an agent typed signatures to anchor an edit on, not guesses.
  • Verification Surface

    5 checks passed2 problems found

    • lowTask runner present

      A Makefile / Taskfile / justfile gives an agent a single index of the project's commands.

      Fix: Add a Makefile / Taskfile / justfile collecting the common commands.

    • lowTypecheck command

      A typecheck script lets an agent catch type errors before they ship.

      Fix: Add a `typecheck` script (e.g. `tsc --noEmit`).

    • Tests present — Runnable tests are the ground truth an agent checks its own edits against.
    • Test command defined — A `test` script is the documented, discoverable way to run the suite.
    • Lint command defined — A linter an agent can run catches a class of mistakes before they ship.
    • CI configured — Readable CI is the feedback loop an agent reads to know what 'green' means here.
    • Build command — A documented build command is the discoverable way for an agent to produce artifacts.
  • Agent Safety

    5 checks passed3 problems found

    • medium.gitignore covers env files

      An ignore rule for .env is what keeps the next careless commit from leaking secrets.

      Fix: Add `.env` (and `.env.*`) to .gitignore.

    • lowCODEOWNERS present

      CODEOWNERS marks the 'don't touch without review' zones an agent should respect.

      Fix: Add a CODEOWNERS file marking the sensitive paths.

    • lowAutomated dependency updates

      Dependabot / Renovate keeps dependencies patched without a human in the loop.

      Fix: Enable Dependabot or Renovate.

    • No committed .env — A tracked real .env hands secrets to anything — including an agent — that reads the repo.
    • No exposed secrets — Secret-shaped literals in tracked files are a live credential leak.
    • .gitignore present — A .gitignore is the first guard against an agent committing secrets or build junk.
    • Security policy — A SECURITY.md is where an autonomous security agent reads this repo's rules before acting on it.
    • License makes the code reusable — Without a license an agent cannot safely copy, redistribute, or vendor any of this code.
  • Context Economy

    2 checks passed2 problems found

    • lowGenerated / vendored files marked

      A .gitattributes linguist marker tells tools (and agents) what to skip.

      Fix: Mark generated/vendored paths in .gitattributes (linguist-generated / linguist-vendored).

    • lowNo oversized source file

      A single file in the hundreds of KB blows past an agent's effective context window.

      Fix: Split the largest files along their natural seams.

    • Dependencies not vendored in — A committed node_modules / vendor tree drowns the real signal an agent needs.
    • Build output not committed — Generated dist/ · build/ output is noise an agent has to read past.

Where the grip slips

  1. highGetting Running+15 pts if fixed

    No local quick-start without external databases

    Getting started requires Docker and a running database (PostgreSQL, MySQL, or SQLite server), or understanding how to configure test databases. A newcomer cannot clone, install, and run a simple example or test suite without external infrastructure. This is a significant friction point compared to projects with bundled test fixtures or in-memory databases.

    Fix: Add a minimal example project (e.g., examples/quick-start/) with a sqlite/:memory: or bundled SQLite database that runs without external setup. Include a README with 'npm install && npm run dev' that starts a working ORM demo in seconds.

  2. mediumFinding Your Way+10 pts if fixed

    Monorepo structure not clearly navigable for code entry points

    While CONTRIBUTING.md documents the directory structure, there is no architecture.md or source code tour explaining where core ORM logic lives, how dialects (PostgreSQL, MySQL, SQLite) are organized, or which file to read first to understand the query builder. A newcomer reading drizzle-orm/src/ will struggle to find the main entry points.

    Fix: Create docs/ARCHITECTURE.md or docs/CODEBASE.md explaining: (1) how the monorepo is organized, (2) key files in drizzle-orm/src (e.g., query builders, type system, drivers), (3) how to find and modify dialect-specific code, and (4) a suggested reading order for new contributors.

  3. mediumPath To Contribute+8 pts if fixed

    No visible 'good first issue' label or beginner-friendly issue queue

    CONTRIBUTING.md points to the issue form but does not mention an issue label strategy or link to beginner/help-wanted issues. With 1851 open issues, a newcomer has no curated on-ramp to find tasks suitable for their skill level, making the path to first contribution feel overwhelming.

    Fix: Add a section in CONTRIBUTING.md: 'Finding Your First Issue' with a link to filtered issues (e.g., GitHub query: label:good-first-issue OR label:help-wanted). Ensure the project uses these labels consistently on issues suitable for newcomers.

  4. mediumPath To Contribute+7 pts if fixed

    PR guidelines and commit message conventions are truncated or incomplete

    The CONTRIBUTING.md file cuts off mid-section ('Building the project' section ends abruptly), and the visible PR guidelines sections for drizzle-orm and drizzle-kit are labeled but content is not shown in the snapshot. A newcomer cannot determine code style expectations, commit message format, branch naming, or PR review turnaround.

    Fix: Ensure CONTRIBUTING.md is complete in the repo and includes explicit PR guidelines: (1) commit message format (e.g., 'feat: add X' / 'fix: resolve Y'), (2) branch naming convention, (3) code style enforced by ESLint/prettier (visible in root), (4) when and how to request review from core contributors.

  5. lowGetting Running+5 pts if fixed

    No TypeScript setup or build verification example for local development

    The root package.json shows TypeScript 5.6.3 is pinned, but there is no example of how to configure a local IDE (VSCode, etc.) or how to verify TypeScript compilation and type checking locally. A newcomer on Windows or unfamiliar with monorepo tooling may struggle to get tsc/tsup to work.

    Fix: Add a 'Local Development Setup' section in CONTRIBUTING.md with: (1) verified IDE config (.vscode/settings.json example), (2) command to run type-check (e.g., 'pnpm test:types'), (3) how to run linting (dprint check/fmt shown in root scripts) and ensure it passes before commit.

Show your score

Latch badge
[![Latch score](https://latch.fyi/api/badge/c343e768-fce0-43c0-8e87-5fe20607a0c6)](https://latch.fyi/drizzle-team/drizzle-orm)

Share this analysis

https://latch.fyi/drizzle-team/drizzle-orm

Fixed some issues? Re-analyze to measure your progress →

Copy the whole report

Grab the entire verdict in one go — a Markdown block for a README or an issue, plain text, or a prompt you can paste straight into an LLM.

Was this verdict fair?

One tap helps — or tell us more.