Package.json-generator

package.json
Nästa

Istället för att köra npm init och svara på elva frågor, fyll i ett formulär och få tillbaka en prydlig, korrekt strukturerad package.json. Den här generatorn täcker de obligatoriska fälten (name, version), de vanligt använda (scripts, dependencies, devDependencies, engines) och finesserna (repository, bugs, keywords, license) som gör ett paket upptäckbart och publicerbart.

Så genererar du din package.json

  1. 1

    Ange namn och version

    Namnet följer npm-regler: gemener, URL-säkert, under 214 tecken. Versionen är semver (t.ex. 0.1.0).

  2. 2

    Välj modultypen

    CommonJS (standard) eller ESM via "type": "module". Spelar roll för Node.js 14+-projekt.

  3. 3

    Lägg till skript

    Start, build, test, lint: kommandona körs med `npm run <name>`.

  4. 4

    Lista beroenden

    Körtidspaket i dependencies, verktyg i devDependencies.

  5. 5

    Ställ in metadata

    Beskrivning, författare, licens, repository-URL, nyckelord.

  6. 6

    Kopiera utdatan

    Klistra in i en ny package.json i projektets rot.

Fälten som spelar störst roll

Fält Obligatoriskt? Anteckningar
name Ja Gemener, 1–214 tecken, URL-säkert
version Ja Semver (major.minor.patch)
type Nej “module” för ESM, utelämna för CommonJS
main Rekommenderas Ingångspunkt för CommonJS (index.js)
exports Rekommenderas Modern exports-karta för dubbel CJS/ESM
scripts Starkt rekommenderat npm run <name>-kommandon
dependencies Efter behov Körtidspaket
devDependencies Efter behov Byggverktyg, testkörare, linters
engines Bra att ha Krävt intervall av Node-versioner
license Ja vid publicering SPDX-identifierare som MIT, Apache-2.0

Semver-fusklapp

  • 1.0.0, major.minor.patch
  • ^1.0.0, kompatibel med 1.x.x (>=1.0.0, <2.0.0)
  • ~1.0.0, endast patch-uppdateringar (>=1.0.0, <1.1.0)
  • >=1.0.0 <2.0.0, explicit intervall
  • 1.0.0-beta.1, förhandsutgåva
  • latest, npm-tagg, inte en version

Standard vid körning av npm install package är ^, vilket tillåter icke-brytande uppgraderingar.

Standardskript värda att ha

{
  "scripts": {
    "start": "node index.js",
    "dev": "nodemon index.js",
    "build": "tsc",
    "test": "vitest",
    "lint": "eslint .",
    "format": "prettier --write ."
  }
}

Namngivningsfallgropar

  • Inga versaler. MyPackage misslyckas med npm install.
  • Inga mellanslag. Använd bindestreck: my-package.
  • Scopade namn börjar med @org/ för GitHub- eller npm-organisationer: @acme/utils.
  • Reserverade ord. node_modules, favicon.ico, core, express kan inte användas som paketnamn.

Licensalternativ

Välj en erkänd SPDX-identifierare:

  • MIT, det mest tillåtande vanliga valet.
  • Apache-2.0, tillåtande med patentlicens.
  • ISC, mycket kort MIT-liknande licens, npm-standard.
  • GPL-3.0-or-later, copyleft.
  • UNLICENSED, privat paket, inte för distribution.

Felaktiga eller tvetydiga licenssträngar utlöser varningar vid npm publish.

Vanliga frågor

Dependencies installeras när någon kör npm install i ett projekt som använder ditt. devDependencies installeras bara i paketets egen utvecklingsmiljö. Lägg körtidspaket i dependencies och test-/byggverktyg i devDependencies.

Ja, för applikationer. Lockfilen låser exakta versioner och säkerställer reproducerbara installationer mellan maskiner och CI. För bibliotekspaket som publiceras till npm är lockfilen valfri, konsumenter får sin egen lockfil.

Endast om du vill att paketet ska vara ESM (import/export-syntax) som standard. Utan det behandlas .js-filer som CommonJS. Du kan också använda .mjs för ESM-filer eller .cjs för CommonJS-filer oavsett “type”.

De Node-versioner som din kod har testats mot. Ett typiskt val idag är "engines": {"node": ">=18"}. Det är en varning, inte ett fel, men verktyg respekterar det och användare låser korrekt.

Relaterade verktyg

Verktyget finns på andra språk