Softonic

Generator package.json

Krok 1 / 2 package.json
Dalej

Zamiast uruchamiać program npm init i odpowiadać na jedenastu pytań, wypełnij formularz i otrzymasz uporządkowany, poprawnie strukturalizowany plik package.json. Ten generator obejmuje wymagane pola (nazwa, wersja), powszechnie używane elementy (skrypty, zależności, zależności rozwojowe, silniki) oraz dodatkowe informacje (repositorium, błędy, kluczowe słowa, licencja), które umożliwiają łatwe odnalezienie i publikowanie pakietu.

Jak stworzyć plik package.json

  1. 1

    Wpisz nazwę i wersję

    Nazwa musi spełniać zasady npm: być napisaną małymi literami, bezpieczną pod względem URL oraz nie przekraczać 214 znaków. Wersja musi być typu semver (np. 0.1.0).

  2. 2

    Wybierz typ modułu

    CommonJS (domyślnie) lub ESM za pomocą typu „module". Wymaga się tego dla projektów Node.js 14 i wyższych wersji.

  3. 3

    Dodaj skripty

    Uruchom, stwórz, sprawdź, popraw – te komendy są wykonywane za pomocą `npm run <name>`.

  4. 4

    Spis zależności

    Pakety runtime znajdują się w zależnościach, a narzędzia – w zależnościach rozwojowych.

  5. 5

    Ustaw metadane

    Opis, autor, licencja, adres URL repozytorium oraz kluczowe słowa.

  6. 6

    Kopij wynik.

    Wklej do nowego pliku package.json w korzeniu projektu.

Pole, które ma największe znaczenie

Pole Obowiązkowe? Uwagi
name Tak W małych literach, od 1 do 214 znaków, bezpieczne dla adresów URL
version Tak Semver (wersja główna, wersja dodatkowa, poprawka)
type Nie “module” dla ESM; pomijany dla CommonJS
main Zalecane Punkt wejścia do CommonJS (index.js)
exports Zalecane Mapa współczesnych eksportów dla systemów CJS/ESM typu dual
scripts Zdecydowanie zalecane Komendy npm run <name>
dependencies Według potrzeb Pakety do uruchomienia
devDependencies Według potrzeb narzędzia do budowy, programy do testowania oraz programy do analizy kodu
engines Warto mieć wymagany zakres wersji węzła
license Tak – do publikacji Identyfikator SPDX, np. MIT, Apache-2.0

List przewodnikowy do metody Semver

  • 1.0.0, major.minor.patch
  • ^1.0.0 – kompatybilny z wersjami 1.x.x (≥1.0.0, <2.0.0)
  • ~1.0.0 – wyłącznie aktualizacje poprawek (≥ 1.0.0, < 1.1.0)
  • >=1.0.0 <2.0.0 – wyraźny zakres
  • 1.0.0-beta.1, prerelease
  • latest – etykieta npm, nie jest wersją

Wartością standardową przy uruchamianiu npm install package jest ^, co umożliwia aktualizacje bez przerwania działania systemu.

Standardowe skripty, które warto mieć

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

Pułapki przy nadawaniu nazw

  • Bez wielkich liter. MyPackage nie przechodzi npm install.
  • Bez spacji. Używaj łączników: my-package.
  • Nazwy z zakresem (scoped) zaczynają się od @org/ dla organizacji na GitHub lub npm: @acme/utils.
  • Słowa zarezerwowane. node_modules, favicon.ico, core i express nie mogą być używane jako nazwy pakietów.

Opcje licencji

Wybierz uznany identyfikator SPDX:

  • MIT – najbardziej permisywny, powszechny wybór.
  • Apache-2.0 – permisywna, z udzieleniem patentu.
  • ISC – bardzo krótka licencja typu MIT, domyślna w npm.
  • GPL-3.0-or-later – copyleft.
  • UNLICENSED – pakiet prywatny, nie przeznaczony do dystrybucji.

Niewłaściwe lub niejednoznaczne ciągi licencji wywołują ostrzeżenia podczas publikacji na npm.

Najczęściej zadawane pytania

Zależności są instalowane, gdy ktoś uruchamia program npm install w projekcie, który wykorzystuje twoje oprogramowanie. Zależności rozwojowe (devDependencies) są instalowane wyłącznie w własnym środowisku rozwojowym pakietu. Pakety do czasu wykonywania należy umieszczać w kategorii dependencies, a narzędzia do testowania i budowy – w kategorii devDependencies.

Tak, w przypadku aplikacji. Plik lockfile określa dokładne wersje i gwarantuje powtarzalne instalacje na różnych urządzeniach oraz w procesie CI. W przypadku pakietów bibliotecznych publikowanych na npm plik lockfile jest opcjonalny – użytkownicy otrzymują własny plik lockfile.

Tylko jeśli chcesz, aby pakiet był ustawiony jako ESM (zgodnie z syntaksą importu i eksportu) w standardowym ustawieniu. W przypadku braku tej opcji pliki .js są traktowane jako CommonJS. Można również używać plików .mjs do plików ESM lub plików .cjs do plików CommonJS, niezależnie od ich typu.

Wersje nodów, na których został przetestowany twój kod. Obecnie powszechną wersją jest "engines": {"node": ">=18"}. Jest to ostrzeżenie, a nie błąd, jednak narzędzia go uwzględniają, a użytkownicy poprawnie go zaznaczają.

Powiązane narzędzia

Tabela ASCII

Pełna tabela ASCII od 0 do 127 z zapisem dziesiętnym, szesnastkowym, ósemkowym i binarnym oraz notacją numerycznych odwołań HTML, w tym kodami sterującymi NUL, LF i DEL.

Referencja znaków HTML

Przeszukiwalna lista encji HTML wraz z ich kodami nazwanymi i liczbowymi oraz kopiowaniem jednym kliknięciem specjalnych znaków i symboli.

Skróty klawiaturowe

Wyszukuj udokumentowane skróty domyślne VS Code, Chrome i Bash z GNU Readline w macOS, Windows i Linux.

Generator EditorConfig

Wygeneruj plik .editorconfig z własnymi regułami stylu i rozmiaru wcięć, końca linii, kodowania i białych znaków, aby uzyskać spójne formatowanie w różnych IDE i edytorach.

Walidator adresów e-mail

Zweryfikuj adres e-mail: sprawdzenie składni RFC 5322, sprawdzenie rekordu MX w czasie rzeczywistym oraz szczegóły dotyczące części lokalnej, domeny i długości. Żadna wiadomość nie jest wysyłana.

Formatowanie HTML

Formatuj HTML lokalnie w przeglądarce, używając wcięć dwóch lub czterech spacji. HTML nie jest wysyłany ani walidowany.

Narzędzie jest dostępne w innych językach