{
  "name": "@blobatar/react",
  "version": "2.7.0",
  "description": "React adapter for blobatar \u2014 deterministic geometric avatars.",
  "type": "module",
  "sideEffects": [
    "*.css"
  ],
  "files": [
    "dist",
    "src",
    "README.md",
    "LICENSE"
  ],
  "main": "./dist/index.js",
  "types": "./dist/index.d.ts",
  "exports": {
    ".": {
      "types": "./dist/index.d.ts",
      "default": "./dist/index.js"
    },
    "./gaze": {
      "types": "./dist/gaze.d.ts",
      "default": "./dist/gaze.js"
    },
    "./package.json": "./package.json"
  },
  "publishConfig": {
    "access": "public"
  },
  "scripts": {
    "build": "bun scripts/build.ts",
    "typecheck": "tsc -p tsconfig.json --noEmit",
    "check": "bun run typecheck",
    "//prepack": "This does not contradict `//check` below, and the difference is who owns the build. Under `check`, turbo owns it: the `build` task runs once for the whole workspace before any check reads a `dist`, so a check that rebuilt its own package would delete one out from under a concurrent check in another. Under `npm pack` and `npm publish` there is no turbo and no ordering \u2014 npm runs one lifecycle in one package \u2014 so without this the tarball is whatever `dist` happened to be on disk, which for a package built from a peer dependency can be stale, from another branch, or absent entirely. Core carried this from the start; the adapters were published by hand once without it, and only a manual `npm pack --dry-run` caught that the contents were right.",
    "prepack": "bun run build"
  },
  "//peerDependencies": "`blobatar` is pinned to an exact major, not `^3`. Every package in this set publishes the same version (`.changeset/config.json`), and npm does not enforce that at install time \u2014 without the exact range, `@blobatar/react@4` resolves happily alongside `blobatar@3` and renders a different generation's faces from a package the consumer believes is current. Under ADR-0008 the major names the generation, so a mixed pair is not a version skew, it is the wrong picture. `packages/harness` asserts this range rather than trusting it, because release tooling rewrites workspace ranges and would quietly turn it into a caret.",
  "peerDependencies": {
    "blobatar": "2.x",
    "react": ">=18"
  },
  "devDependencies": {
    "@types/react": "^19",
    "blobatar": "workspace:*",
    "react": "^19"
  },
  "keywords": [
    "blobatar",
    "avatar",
    "identicon",
    "react",
    "svg",
    "deterministic",
    "shadcn",
    "shadcn-ui",
    "shadcn-registry"
  ],
  "license": "MIT",
  "author": "Alain",
  "repository": {
    "type": "git",
    "url": "git+https://github.com/Alain00/blobatar.git",
    "directory": "packages/react"
  },
  "homepage": "https://github.com/Alain00/blobatar#readme",
  "bugs": "https://github.com/Alain00/blobatar/issues",
  "//check": "No `bun run build` here. The build is a turbo task that `check` depends on, so it runs once for the whole workspace before any check reads a `dist` \u2014 a check that rebuilt its own package would delete `dist` out from under a concurrent check in another one."
}