{
"markdown": "# Packkit π¦\n\n> A highly configurable generator for modern **JS/TS projects** β packages, CLIs, apps, services, and full-stack repos β from a CLI **or** a web configurator, with a stable embedded API and safe upgrades.\n\n[](https://www.npmjs.com/package/create-packkit)\n[](https://www.npmjs.com/package/create-packkit)\n[](https://github.com/PackkitLabs/create-packkit-js/actions/workflows/ci.yml)\n[](https://packagephobia.com/result?p=create-packkit)\n[](LICENSE)\n
\n[](https://packkit-web.pages.dev/)\n[](https://github.com/PackkitLabs/packkit-mcp)\n[](https://packkitlabs.github.io/create-packkit-js/llms.txt)\n[](CONTRIBUTING.md)\n\nMost scaffolders lock you into one stack, one language, and the terminal. Packkit lets you **choose** β TypeScript or JavaScript, library, CLI, app, service, or full-stack monorepo, ESM/CJS/dual, your bundler, test runner, linter, git hooks, release flow, GitHub Actions and more β and it works from a CLI **or** a browser page that downloads your project as a zip.\n\n## Quick start\n\n```sh\n# interactive wizard\nnpm create packkit@latest\n# or with npx\nnpx create-packkit\n\n# skip the wizard with a preset\nnpx create-packkit ts-lib my-lib\nnpx create-packkit cli my-tool\nnpx create-packkit --preset full my-pkg --pm pnpm\n```\n\nThen `cd`, and you already have a working project β `build`, `test`, and `lint` all pass out of the box.\n\n## Create the repo, not just the folder\n\nPackkit can create the remote and push the first commit, so you don't have to make an empty repo in a browser first:\n\n```sh\n# create it on GitHub (private) and push\nnpx create-packkit ts-lib my-lib --github\n\n# public instead\nnpx create-packkit ts-lib my-lib --github --public\n\n# any other host β GitLab, Bitbucket, Gitea, self-hosted\nnpx create-packkit ts-lib my-lib --git-remote git@bitbucket.org:me/my-lib.git\n```\n\n`--github` shells out to the [GitHub CLI](https://cli.github.com), so **Packkit never asks for, reads, or stores a token** β `gh` already holds your credentials. Created repos are **private unless you pass `--public`**.\n\nThis also fixes your links: the repository URL is baked into `package.json` and the README's CI badges when the files are generated, so letting Packkit resolve it up front means the badges point somewhere real from the first commit.\n\n### Scaffolding into a repo you already have\n\nAlready cloned an empty repo, or started some work? `--merge` scaffolds around what's there:\n\n```sh\ngit clone git@github.com:me/my-lib.git && cd my-lib\nnpx create-packkit ts-lib my-lib --here --merge\n```\n\n**Existing files are never overwritten.** Anything that collides is left alone and reported, so you can diff at your leisure. (A directory containing only `.git` counts as empty β a fresh clone scaffolds without needing `--merge` at all.)\n\n## Keep a project current\n\nEvery scaffolded project records what it came from in `packkit.json`. Later, from\ninside the project:\n\n```sh\nnpx create-packkit upgrade # dry run: what's changed since you scaffolded\nnpx create-packkit upgrade --apply # bring in the additive changes, keep your edits\n```\n\nUpgrade regenerates the project Packkit would produce today and diffs it against\ndisk. **`--apply` is non-destructive**: it brings in *additions* and preserves\nanything that already exists but differs β because without a stored baseline it\ncan't tell a template change from your own edit. Replacing differing values is\nopt-in, per category:\n\n| Change | Default `--apply` | Explicit replacement |\n| --------------------- | ----------------- | -------------------------- |\n| New file | Applied | Applied |\n| Changed file | Preserved | `--replace-files` (or `--force`) |\n| New script | Applied | Applied |\n| Changed script | Preserved | `--update-scripts` (or `--force`) |\n| New dependency | Applied | Applied |\n| Changed dependency | Preserved | `--update-deps` (or `--force`) |\n| Changed package field | Preserved | `--force` |\n| Removed template file | Reported | No automatic deletion |\n\nYour own files, scripts, and dependencies are never touched by `--apply`. The\nreport lists everything preserved so you can review it and opt into replacement\nwhere you want Packkit's version.\n\n**Baseline-aware (new projects).** Projects scaffolded with Packkit 3.3+ record\na baseline of what was generated (in `packkit.json`), so upgrade can do a\nthree-way comparison and tell the difference between a change *you* made and one\nthe *template* made:\n\n- **template-only change** (you didn't edit it) β applied by `--apply`, safely;\n- **your edit** (the template didn't change) β preserved;\n- **both changed** β flagged as a conflict to review.\n\n**Older projects** without a baseline fall back to the conservative rule:\nanything that differs is preserved for review.\n\nEither way, `--apply` never overwrites your own edits or resolves conflicts for\nyou β those are always preserved. `--json` reports the classification and\n`baselineAvailable` for automation.\n\n**Honest provenance.** After an upgrade, `packkit.json` records what actually\nhappened rather than claiming the project is a fresh scaffold of the new\nversion. `version` (the version you generated with) is left untouched;\n`lastUpgradeAppliedWith` records the version applied, and `upgradeStatus` is\n`current` only when nothing was left behind β a partial upgrade that preserved\nyour edits is marked `partial` with an `unresolvedChanges` count.\n\n## Or configure it on the web\n\nNo install needed: **[packkit-web.pages.dev](https://packkit-web.pages.dev/)** β pick a language (JS/TS or Python), tick the options, preview the file tree, and **download a zip** (or copy the equivalent command). Everything runs in your browser.\n\n## Options reference\n\nEvery flag, its values (**default** in bold), and what it's for. Prefer the interactive [web configurator](https://packkit-web.pages.dev/) β the same descriptions appear as you hover. _This table is generated from the schema (`npm run gen:reference`)._\n\n\n\n### Package\n\n| Flag | Values | What it does |\n|---|---|---|\n| `--name` | β | The npm package name. Scoped names like `@you/pkg` are fine. |\n| `--description` | β | One-line summary β used in package.json and the README heading. |\n| `--author` | β | Your name (and optionally email/URL). Populates package.json + LICENSE. |\n| `--keywords` | β | Comma-separated npm keywords to help people discover the package. |\n| `--repo` | β | Git repository URL. Wires up repository/bugs/homepage links and CI badges. |\n\n### Core\n\n| Flag | Values | What it does |\n|---|---|---|\n| `--language` | **ts** Β· js | TypeScript (strict, recommended) or plain ESM JavaScript. TS gives you types, editor help, and generated .d.ts for consumers. |\n| `--module` | **esm** Β· dual Β· cjs | How the package is consumed. ESM-only (default) is the modern, leanest choice β Node 20.19+/22.12+ can `require()` ESM. Pick dual only if you must support older CJS-only consumers; cjs-only is rarely needed. |\n| `--server` | **hono** Β· fastify Β· express | For the service target: Hono (fast, web-standard, tiny β default), Fastify (batteries-included, plugins, schema validation), or Express (ubiquitous, huge ecosystem). |\n| `--target` | **library** Β· cli Β· service Β· app Β· worker | What you are building β mix and match: a library (importable package), a CLI (ships a bin), an HTTP service, or an app (Vite SPA). |\n| `--monorepo` | on / off (default: **off**) | Generate a pnpm + Turborepo workspace with two linked example packages and Changesets. Only worth it when β₯2 packages share code. |\n| `--monorepo-layout` | **libraries** Β· fullstack | What the workspace contains. \"libraries\" gives linked packages you publish (Changesets). \"fullstack\" gives apps/web (React+Vite) + apps/server (Hono by default; --server for Fastify/Express) + packages/shared, wired together, with the server serving the web build in production. |\n| `--framework` | **none** Β· react Β· vue Β· svelte | UI framework for component libraries and apps: React, Vue, or Svelte (or none for a plain package). |\n| `--pm` | **npm** Β· pnpm Β· yarn Β· bun | Which package manager the scripts, lockfile, and CI target: npm, pnpm, yarn, or bun. |\n| `--node` | 22 Β· **24** Β· 26 | Minimum Node line to support. Choices track Nodeβs own release schedule (Active LTS is the default); this sets engines + .nvmrc. |\n\n### Build\n\n| Flag | Values | What it does |\n|---|---|---|\n| `--bundler` | **tsup** Β· tsdown Β· unbuild Β· rollup Β· none | How the library is built. tsup (default, esbuild-fast) and tsdown suit most libs; unbuild for zero-config; rollup for full control; none = tsc-only (or no build). |\n| `--minify` | on / off (default: **off**) | Minify the build output. Best for CLIs and browser bundles; usually unnecessary for libraries (consumers minify). |\n| `--no-sourcemaps` | on / off (default: **on**) | Ship source + JS/declaration maps so consumers can step into and go-to-definition on your original code when debugging. On by default for libraries. |\n\n### Quality\n\n| Flag | Values | What it does |\n|---|---|---|\n| `--test` | **vitest** Β· jest Β· node Β· none | Test runner: Vitest (fast, Vite-native, default), Jest (classic, huge ecosystem), or Nodeβs built-in node:test (zero deps). |\n| `--no-coverage` | on / off (default: **on**) | Collect code-coverage reports (v8) and add a `coverage` script. Pairs with the Codecov workflow. |\n| `--storybook` | on / off (default: **off**) | Add Storybook to develop and document components in isolation. Component libraries only. |\n| `--e2e` | on / off (default: **off**) | Add Playwright end-to-end tests for app targets: a config that boots your dev server, an example spec, and a CI job. |\n| `--env` | on / off (default: **off**) | Type-safe environment variables: a Zod-validated `src/env.ts` that fails fast on misconfig, plus a `.env.example`. For services and CLIs. |\n| `--pkg-checks` | on / off (default: **off**) | Verify the published package is correct with publint + are-the-types-wrong (exports map, types resolution, ESM/CJS). Highly recommended for libraries. |\n| `--knip` | on / off (default: **off**) | Find unused files, dependencies, and exports so the project doesnβt accumulate dead weight. |\n| `--size-limit` | on / off (default: **off**) | Add a bundle-size budget (size-limit) that measures your built entry and fails CI if it exceeds the limit β catches accidental bloat. |\n| `--doctor` | on / off (default: **off**) | Add an env doctor (`npm run doctor`) that warns when the local Node / package manager donβt match what the project expects. Warn-only. |\n| `--lint` | **eslint-prettier** Β· biome Β· oxlint Β· none | Linter + formatter: ESLint + Prettier (default, most compatible), Biome (one fast tool for both), or oxlint (Rust-fast linting). |\n| `--hooks` | **simple-git-hooks** Β· husky Β· lefthook Β· none | Pre-commit hooks that run lint-staged: simple-git-hooks (tiny, default), husky (popular), or lefthook (fast, parallel). |\n\n### Release\n\n| Flag | Values | What it does |\n|---|---|---|\n| `--canary` | on / off (default: **off**) | Add a workflow that publishes snapshot builds (x.y.z-canary-) to a `canary` dist-tag so people can test unreleased changes. Requires Changesets. |\n| `--release` | **changesets** Β· release-it Β· np Β· none | How you version + publish: Changesets (default, great for libraries and monorepos), release-it, np, or none. |\n| `--jsr` | on / off (default: **off**) | Also publish to JSR, the TypeScript-first registry. For plain ESM TypeScript libraries. |\n\n### CI / CD\n\n| Flag | Values | What it does |\n|---|---|---|\n| `--workflows` | **ci** Β· **npm-publish** Β· pages Β· codeql Β· codecov Β· stale | GitHub Actions to include: ci (lint/test/build), npm-publish (provenance), pages (deploy Storybook/site), codeql (security), codecov (coverage), stale. |\n| `--deps` | **renovate** Β· dependabot Β· none | Automated dependency updates: Renovate (default, powerful) or Dependabot (built into GitHub). |\n\n### Repository\n\n| Flag | Values | What it does |\n|---|---|---|\n| `--license` | **MIT** Β· Apache-2.0 Β· ISC Β· none | Open-source license for the LICENSE file and package.json (MIT recommended), or none. |\n| `--no-community` | on / off (default: **on**) | Community health files: CONTRIBUTING, CODE_OF_CONDUCT, SECURITY, and issue/PR templates. |\n| `--no-agents` | on / off (default: **on**) | AI-agent instructions (AGENTS.md + CLAUDE.md) so coding agents know how to build, test, and work in the repo. |\n| `--no-vscode` | on / off (default: **on**) | VS Code workspace settings + recommended-extensions so the repo is set up consistently on open. |\n| `--no-editorconfig` | on / off (default: **on**) | An .editorconfig so every editor uses the same indentation and line endings. |\n| `--no-git` | on / off (default: **on**) | Run `git init` and make an initial commit after scaffolding. |\n| `--no-install` | on / off (default: **on**) | Install dependencies automatically after scaffolding. |\n\n\n\n## Presets\n\nNamed bundles of the options above β `npx packkit -y`.\n\n\n\n| Preset | Shortcut | What you get |\n|---|---|---|\n| `ts-lib` | `lib` | TypeScript library β ESM-only, tsup, Vitest, ESLint. |\n| `js-lib` | `jslib` | JavaScript (ESM) library β tsup, Vitest, ESLint. |\n| `ts-cli` | β | TypeScript CLI + library β ESM, ships a bin. |\n| `cli` | β | TypeScript CLI tool β ESM, ships a bin. |\n| `react-lib` | `rlib` | React component library (TS) β JSX, peer deps, jsdom tests. |\n| `react-lib-js` | β | React component library (JS) β JSX, peer deps, jsdom tests. |\n| `react-app` | `rapp` | React SPA β Vite dev server, build, Testing Library. |\n| `vue-lib` | `vlib` | Vue component library β Vite lib build (SFCs), ESM + types. |\n| `vue-app` | `vapp` | Vue SPA β Vite dev server, build, Testing Library. |\n| `svelte-lib` | `slib` | Svelte component library β ships source, peer svelte, jsdom tests. |\n| `svelte-app` | `sapp` | Svelte SPA β Vite dev server, build, Testing Library. |\n| `node-service` | `svc`, `service` | Node HTTP service (Hono) β tsx dev, tsup build, Dockerfile. |\n| `node-worker` | `worker` | Node background worker β queue/event consumer: handler seam, SIGTERM drain, JSON logs, poison seam, Dockerfile (no HTTP port). No transport SDK. |\n| `monorepo` | β | pnpm + Turborepo workspace β two example packages, Changesets, CI. |\n| `fullstack` | `fs`, `app` | Full-stack monorepo β React+Vite web, Hono/Fastify/Express API (--server), shared package; server serves the web build in production. |\n| `oss` | β | Full open-source library β coverage, CodeQL, Codecov, Renovate, Changesets. |\n| `minimal` | β | Bare TS library β tsup only, no tests/lint/CI. |\n| `full` | β | Everything on β library + CLI, all workflows and extras. |\n\n\n\n**Team profiles:** save a partial config as `packkit.config.json` (or any file) and reuse it with `npx create-packkit my-lib --from ./packkit.config.json` β flags still override the file.\n\n## For AI agents & automation\n\nPackkit is safe to drive non-interactively β every option is a flag, so no prompts are needed. Agents can introspect the whole interface as JSON:\n\n```sh\nnpx create-packkit --schema # all options, presets, and aliases as JSON\nnpx create-packkit my-lib ts-lib --no-install --no-git # deterministic scaffold\n```\n\nThere's also an [`llms.txt`](llms.txt) (served at [packkitlabs.github.io/create-packkit-js/llms.txt](https://packkitlabs.github.io/create-packkit-js/llms.txt)) describing the commands for LLMs.\n\n**MCP server** β [`packkit-mcp`](https://github.com/PackkitLabs/packkit-mcp) exposes every Packkit generator (JS/TS + Python) as native [Model Context Protocol](https://modelcontextprotocol.io) tools. Add to your agent's MCP config:\n\n```json\n{ \"mcpServers\": { \"packkit\": { \"command\": \"npx\", \"args\": [\"-y\", \"packkit-mcp\"] } } }\n```\n\n## Embed Packkit in your own app\n\nPackkit ships a typed, side-effect-free API so a Node application can use it as a\nproject-generation engine β generate in memory, add your own deployment files,\nand write to disk when you're ready. No prompts, installs, git, or network.\n\n```js\nimport { createProject, extendProject, writeGeneratedProject } from 'create-packkit/embedded';\n\nconst project = createProject({ preset: 'react-app', name: 'weather-dashboard' });\nconst extended = extendProject(project, { files: { '.github/workflows/deploy.yml': deployYaml } });\nawait writeGeneratedProject({ project: extended, destination: '/tmp/weather-dashboard' });\n```\n\nFull guide, including diagnostics, reproducible definitions, digests, and the\nprovider-neutral deployment contract: **[Embedding Packkit](docs/EMBEDDING.md)**.\n\n## How it works\n\nPackkit is a pure `config β { files }` **core** that runs in both Node and the browser:\n\n- the **CLI** writes the files to disk, runs `git init`, and installs dependencies;\n- the **web configurator** zips the same files client-side (no server);\n- the **embedded API** ([`create-packkit/embedded`](docs/EMBEDDING.md)) hands the file map to a host application.\n\nAll three drive from one options schema ([`src/core/options.js`](src/core/options.js)), so they always stay in sync.\n\n## Staying fresh\n\nTwo GitHub Actions keep the templates honest:\n\n- **Dependency freshness** β a weekly check flags any version Packkit writes into generated projects that's fallen a major behind (versions Dependabot can't see), and opens an issue.\n- **Integration** β on any change to generation logic or a template dependency, it generates every preset, installs it, and runs its real checks (build/test/lint, and actually starts services) β so an update can't silently break the projects you'd get.\n\n## License\n\n[MIT](LICENSE) Β© DanMat\n",
"bytes": 18714,
"sha": "483ee597ac2cdd96df548cb0f63d95a401db1501c75e9e019a53a932ddaa3640",
"repo_slug": "danmat/create-packkit",
"fonte": "repo",
"truncated": false,
"api": "https://agentalog.com/api/listings/mcp_io_github_danmat_packkit_mcp_bbf9c4bc/readme"
}