Główny parametr Node.js package.json

Przeprowadziłem już sporo poszukiwań. Jednak nadal mam wątpliwości co do głównego parametru w package.json z Node.js.

1. W jaki sposób wypełnienie tego pola może pomóc? Pytając w inny sposób, czy mogę uruchomić moduł w innym stylu, jeśli to pole przedstawia?
2. Czy w głównym parametrze można wypełnić więcej niż jeden skrypt? Jeśli tak, czy zostałyby rozpoczęte jako dwa wątki? Jeśli nie, jak mogę uruchomić dwa skrypty w module i uruchomić je równolegle?

Wiem, że drugie pytanie jest dość dziwne. Dzieje się tak, ponieważ hostowałem aplikację Node.js w OpenShift, ale aplikacja składa się z dwóch głównych komponentów. Jeden to REST API, a drugi to usługa dostarczania powiadomień.

Obawiam się, że proces dostarczania powiadomień zablokowałby REST API, gdyby zostały zaimplementowane jako jeden wątek. Muszą jednak łączyć się z tą samą kasetą MongoDB. Ponadto chciałbym zaoszczędzić jeden bieg, jeśli oba komponenty mogłyby pracować na tym samym biegu, jeśli to możliwe.

Wszelkie sugestie są mile widziane.

Z dokumentacji npm :

Główne pole to identyfikator modułu, który jest głównym punktem wejścia do programu. Oznacza to, że jeśli twój pakiet nosi nazwę foo, a użytkownik go zainstaluje, a następnie wymaga ("foo"), to zostanie zwrócony obiekt eksportu twojego modułu głównego.

Powinien to być identyfikator modułu w odniesieniu do katalogu głównego folderu pakietu.

W przypadku większości modułów najbardziej sensowne jest posiadanie głównego skryptu, a często niewiele więcej.

Krótko mówiąc:

1. mainParametr jest potrzebny tylko package.jsonwtedy, gdy punkt wejścia do pakietu różni się od index.jsjego folderu głównego. Na przykład ludzie często umieszczają punkt wejścia lib/index.jslub lib/<packagename>.js, w tym przypadku odpowiedni skrypt musi być opisany jako mainw package.json.
2. Nie możesz mieć dwóch skryptów jako main, po prostu dlatego, że punkt wejścia require('yourpackagename')musi być zdefiniowany jednoznacznie.

Odpowiadając na pierwsze pytanie, sposób ładowania modułu zależy od punktu wejścia modułu i głównego parametru pliku package.json .

Załóżmy, że masz następującą strukturę plików:

my-npm-module
|-- lib
|   |-- module.js
|-- package.json

Bez głównego parametru w package.json , trzeba załadować moduł dając punkt wejścia modułu: require('my-npm-module/lib/module.js').

Jeśli ustawisz package.json główny parametr w następujący sposób "main": "lib/module.js", będzie można załadować moduł ten sposób: require('my-npm-module').

Jeśli masz na przykład w swoim package.jsonpliku:

{
"name": "zig-zag",
"main": "lib/entry.js",
...
}

lib/entry.js będzie głównym punktem wejścia do twojego pakietu.

Dzwoniąc

require('zig-zag');

w węźle lib/entry.jsbędzie właściwy plik, który jest wymagany.

Jedną z ważnych funkcji mainklucza jest to, że zapewnia ścieżkę do punktu wejścia. Jest to bardzo pomocne podczas pracy z nodemon. Jeśli pracujesz z nodemoni zdefiniujesz mainklucz w swoim, package.jsonpowiedzmy "main": "./src/server/app.js", możesz po prostu podkręcić serwer, wpisując nodemonCLI z rootem jako pwd zamiast nodemon ./src/server/app.js .

O ile wiem, jest to główny punkt wejścia do pakietu węzłów (biblioteki) dla npm. Jest to potrzebne tylko wtedy, gdy projekt npm staje się pakietem węzłów (biblioteką), które mogą być instalowane przez npm przez innych.

Powiedzmy, że masz bibliotekę z folderem build /, dist / lub lib /. W tym folderze masz następujący skompilowany plik dla swojej biblioteki:

-lib/
--bundle.js

Następnie w pliku package.json powiesz npm, jak uzyskać dostęp do biblioteki (pakiet węzłów):

{
  "name": "my-library-name",
  "main": "lib/bundle.js",
  ...
}

Po zainstalowaniu pakietu węzła z KMP do projektu JS, można importować funkcjonalności z dołączonym bundle.js pliku:

import { add, subtract } from 'my-library-name';

Odnosi się to również do korzystania z dzielenia kodu (np. Webpack) w bibliotece. Na przykład ten plik webpack.config.js wykorzystuje kod, który dzieli projekt na wiele pakietów zamiast jednego.

module.exports = {
  entry: {
    main: './src/index.js',
    add: './src/add.js',
    subtract: './src/subtract.js',
  },
  output: {
    path: `${__dirname}/lib`,
    filename: '[name].js',
    library: 'my-library-name',
    libraryTarget: 'umd',
  },
  ...
}

Mimo to możesz zdefiniować jeden główny punkt wejścia do swojej biblioteki w swoim package.json :

{
  "name": "my-library-name",
  "main": "lib/main.js",
  ...
}

Następnie korzystając z biblioteki, możesz importować pliki z głównego punktu wejścia:

import { add, subtract } from 'my-library-name';

Możesz jednak ominąć główny punkt wejścia z pliku package.json i zaimportować podzielone pakiety kodu:

import add from 'my-library-name/lib/add';
import subtract from 'my-library-name/lib/subtract';

W końcu główna właściwość w pliku package.json wskazuje tylko na główny plik punktu wejścia w bibliotece.

Dla OpenShift, można dostać tylko jedną parę portu i IP do wiązania (na wniosek). Wygląda na to, że powinieneś móc obsługiwać obie usługi z jednego wystąpienia nodejs, dodając trasy wewnętrzne dla każdego punktu końcowego usługi.

Mam tutaj informacje o tym, jak OpenShift używa pliku package.json twojego projektu do rozpoczęcia aplikacji: https://www.openshift.com/blogs/run-your-nodejs-projects-on-openshift-in-two-simple-steps #package_json

Potraktuj to tylko jako „punkt wyjścia”.

W sensie programowania obiektowego, powiedzmy C #, jest to init () lub konstruktor klasy obiektów, to właśnie oznaczał „punkt wejścia”.

Na przykład

public class IamMain  // when export and require this guy
{
    public IamMain()  // this is "main"
    {...}

    ...   // many others such as function, properties, etc.
}