Node.js
pakiet.json

Uwagi

npm init

Podstawowa definicja projektu

{
    "name": "my-project",
    "version": "0.0.1",
    "description": "This is a project.",
    "author": "Someone <[email protected]>",
    "contributors": [{
        "name": "Someone Else",
        "email": "[email protected]"
    }],
    "keywords": ["improves", "searching"]
}

Zależności

„zależności”: {„nazwa modułu”: „0.1.0”}

• dokładnie : 0.1.0 zainstaluje tę konkretną wersję modułu.
• najnowsza wersja podrzędna : ^0.1.0 zainstaluje najnowszą wersję podrzędną, na przykład 0.2.0 , ale nie zainstaluje modułu z wyższą wersją główną, np. 1.0.0
• najnowsza łatka : 0.1.x lub ~0.1.0 zainstaluje najnowszą dostępną wersję łatki, na przykład 0.1.4 , ale nie zainstaluje modułu z wyższą wersją główną lub mniejszą, np. 0.2.0 lub 1.0.0 .
• symbol wieloznaczny : * zainstaluje najnowszą wersję modułu.
• repozytorium git : następujące instaluje tarballa z gałęzi master repozytorium git. Można również podać #sha , #tag lub #branch :
  • GitHub : user/project lub user/project#v1.0.0
  • url : git://gitlab.com/user/project.git lub git://gitlab.com/user/project.git#develop
• ścieżka lokalna : file:../lib/project

Po dodaniu ich do pliku package.json użyj polecenia npm install w katalogu projektu w terminalu.

devDependencies

"devDependencies": {
    "module-name": "0.1.0"
}

Dla zależności wymaganych tylko do programowania, takich jak testowanie serwerów proxy stylizacji ext. Te zależności deweloperskie nie zostaną zainstalowane, gdy uruchomimy „instalację npm” w trybie produkcyjnym.

Skrypty

Możesz zdefiniować skrypty, które mogą być uruchamiane lub uruchamiane przed lub po innym skrypcie.

{
  "scripts": {
    "pretest": "scripts/pretest.js",
    "test": "scripts/test.js",
    "posttest": "scripts/posttest.js"
  }
}

W takim przypadku możesz wykonać skrypt, uruchamiając jedno z następujących poleceń:

$ npm run-script test
$ npm run test
$ npm test
$ npm t

Wstępnie zdefiniowane skrypty

Skrypty zdefiniowane przez użytkownika

Możesz także zdefiniować własne skrypty w taki sam sposób, jak w przypadku wstępnie zdefiniowanych skryptów:

{
  "scripts": {
    "preci": "scripts/preci.js",
    "ci": "scripts/ci.js",
    "postci": "scripts/postci.js"
  }
}

W takim przypadku możesz wykonać skrypt, uruchamiając jedno z następujących poleceń:

$ npm run-script ci
$ npm run ci

Skrypty zdefiniowane przez użytkownika obsługuje również skrypty pre i post, jak pokazano w powyższym przykładzie.

Rozszerzona definicja projektu

Niektóre dodatkowe atrybuty są analizowane przez stronę npm, np. repository , bugs lub homepage i wyświetlane w pasku informacyjnym dla tych pakietów

{
  "main": "server.js",  
  "repository" :  {
    "type": "git",
    "url": "git+https://github.com/<accountname>/<repositoryname>.git"
  },
  "bugs": {
    "url": "https://github.com/<accountname>/<repositoryname>/issues"
  },
  "homepage": "https://github.com/<accountname>/<repositoryname>#readme",
  "files": [
    "server.js", // source files
    "README.md", // additional files
    "lib" // folder with all included files
  ]
}

Eksplorowanie pakietu.json

Plik package.json , zwykle obecny w katalogu głównym projektu, zawiera metadane dotyczące aplikacji lub modułu, a także listę zależności do zainstalowania z npm podczas uruchamiania npm install .

Aby zainicjować package.json wpisz w wierszu polecenia npm init .

Aby utworzyć plik package.json z wartościami domyślnymi, użyj:

npm init --yes
# or
npm init -y

Aby zainstalować pakiet i zapisać go w package.json użyj:

npm install {package name} --save

Możesz także użyć zapisu skrótowego:

 npm i -S {package name}

Aliasy NPM -S do --save i -D do --save-dev aby zapisać odpowiednio w zależności od produkcji lub rozwoju.

Pakiet pojawi się w twoich zależnościach; jeśli użyjesz --save-dev zamiast --save , pakiet pojawi się w twoich devDependencies.

Ważne właściwości package.json :

{
  "name": "module-name",
  "version": "10.3.1",
  "description": "An example module to illustrate the usage of a package.json",
  "author": "Your Name <[email protected]>",
  "contributors": [{
    "name": "Foo Bar",
    "email": "[email protected]"
  }],
  "bin": {
    "module-name": "./bin/module-name"
  },
  "scripts": {
    "test": "vows --spec --isolate",
    "start": "node index.js",
    "predeploy": "echo About to deploy",
    "postdeploy": "echo Deployed",
    "prepublish": "coffee --bare --compile --output lib/foo src/foo/*.coffee"
  },
  "main": "lib/foo.js",
  "repository": {
    "type": "git",
    "url": "https://github.com/username/repo"
  },
  "bugs": {
    "url": "https://github.com/username/issues"
  },
  "keywords": [
    "example"
  ],
  "dependencies": {
    "express": "4.2.x"
  },
  "devDependencies": {
    "assume": "<1.0.0 || >=2.3.1 <2.4.5 || >=2.5.2 <3.0.0"
  },
  "peerDependencies": {
    "moment": ">2.0.0"
  },
  "preferGlobal": true,
  "private": true,
  "publishConfig": {
    "registry": "https://your-private-hosted-npm.registry.domain.com"
  },
  "subdomain": "foobar",
  "analyze": true,
  "license": "MIT",
  "files": [
    "lib/foo.js"
  ]
}

Informacje o niektórych ważnych właściwościach:

name

Unikalna nazwa twojego pakietu i powinna być zapisana małymi literami. Ta właściwość jest wymagana, a pakiet nie zostanie zainstalowany bez niej.

1. Nazwa musi być mniejsza lub równa 214 znaków.
2. Nazwa nie może zaczynać się kropką ani podkreśleniem.
3. Nowe paczki nie mogą zawierać wielkich liter w nazwie.

version

Wersja pakietu jest określona przez Semantic Versioning (semver). Który zakłada, że numer wersji jest zapisany jako MAJOR.MINOR.PATCH, a ty zwiększasz:

1. Wersja MAJOR po dokonaniu niezgodnych zmian API
2. Wersja MINOR, gdy dodajesz funkcjonalność w sposób kompatybilny wstecz
3. Wersja PATCH po dokonaniu poprawek błędów kompatybilnych wstecz

description

Opis projektu. Staraj się, aby było to krótkie i zwięzłe.

author

Autor tego pakietu.

bin

Obiekt używany do ujawniania skryptów binarnych z twojego pakietu. Obiekt zakłada, że klucz to nazwa skryptu binarnego, a wartość to względna ścieżka do skryptu.

Ta właściwość jest używana w pakietach zawierających interfejs wiersza polecenia (interfejs wiersza poleceń).

script

Obiekt, który udostępnia dodatkowe polecenia npm. Obiekt zakłada, że kluczem jest polecenie npm, a wartością jest ścieżka do skryptu. Skrypty te można wykonać po uruchomieniu npm run {command name} lub npm run-script {command name} .

Pakiety zawierające interfejs wiersza poleceń i instalowane lokalnie można wywoływać bez ścieżki względnej. Zamiast dzwonić ./node-modules/.bin/mocha , możesz bezpośrednio wywołać mocha .

main

Główny punkt wejścia do twojej paczki. Podczas wywoływania require('{module name}') w węźle będzie to rzeczywisty plik, który jest wymagany.

Zaleca się, aby wymaganie głównego pliku nie generowało żadnych skutków ubocznych. Na przykład wymaganie głównego pliku nie powinno uruchamiać serwera HTTP ani łączyć się z bazą danych. Zamiast tego powinieneś utworzyć coś takiego jak exports.init = function () {...} w głównym skrypcie.

keywords

Tablica słów kluczowych opisujących twoją paczkę. Pomogą one znaleźć Twój pakiet.

devDependencies

Są to zależności, które są przeznaczone wyłącznie do programowania i testowania modułu. Zależności zostaną zainstalowane automatycznie, chyba że zostanie ustawiona zmienna środowiskowa NODE_ENV=production . W takim przypadku możesz nadal używać tych pakietów za pomocą npm install --dev

peerDependencies

Jeśli korzystasz z tego modułu, peerDependencies wyświetla listę modułów, które musisz zainstalować obok tego. Na przykład moment-timezone musi zostać zainstalowana równolegle z moment ponieważ jest chwilową wtyczką, nawet jeśli nie require("moment") bezpośrednio require("moment") .

preferGlobal

Właściwość wskazująca, że ta strona woli być instalowana globalnie przy użyciu npm install -g {module-name} . Ta właściwość jest używana w pakietach zawierających interfejs wiersza polecenia (interfejs wiersza poleceń).

We wszystkich innych sytuacjach NIE należy korzystać z tej właściwości.

publishConfig

PublishingConfig jest obiektem o wartościach konfiguracyjnych, które będą używane do publikowania modułów. Ustawione wartości konfiguracji zastępują domyślną konfigurację npm.

Najczęstszym zastosowaniem publishConfig jest publikowanie pakietu w prywatnym rejestrze npm, więc nadal masz zalety npm, ale dla pakietów prywatnych. Odbywa się to po prostu przez ustawienie adresu URL prywatnego npm jako wartości dla klucza rejestru.

files

Jest to tablica wszystkich plików, które należy uwzględnić w opublikowanym pakiecie. Można użyć ścieżki do pliku lub ścieżki do folderu. Uwzględniona zostanie cała zawartość ścieżki do folderu. Zmniejsza to całkowity rozmiar pakietu, włączając tylko prawidłowe pliki do dystrybucji. To pole działa w połączeniu z .npmignore reguł .npmignore .

Źródło