ipal-kit/docs/publish-checklist.md

Publikacja ipal-kit — checklist

package.json — wymagane pola

{
  "name": "@intecion/ipal-kit",        // scoped pod organizację
  "version": "1.0.0",                   // BUMP przy każdej publikacji (semver)
  "files": ["dist"],                    // tylko dist trafia do pakietu (NIE src)
  "main": "./dist/index.js",
  "types": "./dist/index.d.ts",
  "exports": { ... },                   // wszystkie entry points na ./dist/*
  "publishConfig": {
    "registry": "https://npm.pkg.github.com",
    "exports": { ... }                  // mirror z ./dist (masz to już zrobione)
  },
  "scripts": {
    "build": "...",
    "prepublishOnly": "pnpm clean && pnpm build"   // build ZAWSZE przed publish
  },
  "peerDependencies": {                 // NIE dependencies — klient już je ma
    "payload": "3.84.1",
    "next": ">=15",
    "react": ">=19"
  }
}

Krytyczne przed pierwszą publikacją

• peerDependencies zamiast dependencies dla payload/next/react — inaczej pakiet zaciąga drugą kopię Payloada i wszystko się sypie. @payloadcms/plugin-seo i plugin-form-builder też jako peer (klient pinuje).
• "files": ["dist"] — bez tego do pakietu trafia src/ (widzieliśmy to w stack trace). Sam dist.
• usuń self-reference — sprawdź, że w dependencies NIE ma "ipal-kit": "file:..." (ta zaraza z pnpm add w złym katalogu).
• prepublishOnly buduje przed publikacją — nigdy nie publikuj ręcznie zbudowanego dist (łatwo o nieaktualny).
• bump wersji — koniec z 1.0.0 na zawsze. Każda publikacja = nowy numer. To rozwiązuje cały cykl cache/store prune, który gryzł podczas developmentu.

Publikacja (GitHub Packages)

# jednorazowo: token GitHuba z prawami write:packages w ~/.npmrc
echo "//npm.pkg.github.com/:_authToken=TWÓJ_TOKEN" >> ~/.npmrc

# przy każdym wydaniu
npm version patch    # 1.0.0 → 1.0.1 (albo minor/major)
npm publish

Instalacja u pracownika

# ~/.npmrc w projekcie albo globalnie
@intecion:registry=https://npm.pkg.github.com
//npm.pkg.github.com/:_authToken=ICH_TOKEN

# potem normalnie
pnpm add @intecion/ipal-kit
pnpm add @payloadcms/[email protected] @payloadcms/[email protected] \
         nodemailer lucide-react slugify server-only

README pakietu

Wskaż na docs/getting-started.md jako pierwszy krok. Pracownik z dostępem do rejestru + getting-started postawi projekt bez pytania Ciebie o nic.