Parametro principale di Node.js package.json

Ho già fatto qualche ricerca. Tuttavia, continuando ad avere dubbi sul parametro principale in package.json di Node.js.

1. In che modo sarebbe utile compilare questo campo? Chiedendo in un altro modo, posso avviare il modulo con uno stile diverso se questo campo presenta?
2. Posso avere più di uno script riempito nel parametro principale? Se sì, verrebbero avviati come due thread? Se no, come posso avviare due script in un modulo e farli funzionare in parallelo?

So che la seconda domanda è abbastanza strana. È perché ho ospitato un'applicazione Node.js su OpenShift ma l'applicazione è composta da due componenti principali. Uno è un'API REST e uno è un servizio di consegna delle notifiche.

Temo che il processo di consegna delle notifiche bloccherebbe l'API REST se fossero implementate come un singolo thread. Tuttavia, devono collegarsi alla stessa cartuccia MongoDB. Inoltre, vorrei salvare una marcia se entrambi i componenti potrebbero servire nella stessa marcia, se possibile.

Eventuali suggerimenti sono ben accetti

Dalla documentazione di npm :

Il campo principale è un ID modulo che è il punto di accesso principale al programma. Cioè, se il tuo pacchetto si chiama foo e un utente lo installa e quindi richiede ("foo"), l'oggetto di esportazione del tuo modulo principale verrà restituito.

Questo dovrebbe essere un ID modulo relativo alla radice della cartella del pacchetto.

Per la maggior parte dei moduli, ha più senso avere uno script principale e spesso non molto altro.

Per farla breve:

1. Hai solo bisogno di un mainparametro nel tuo package.jsonse il punto di ingresso al tuo pacchetto differisce dalla index.jssua cartella principale. Ad esempio, le persone spesso inseriscono il punto di accesso lib/index.jso lib/<packagename>.js, in questo caso lo script corrispondente deve essere descritto come mainin package.json.
2. Non è possibile avere due script come main, semplicemente perché il punto di ingresso require('yourpackagename')deve essere definito in modo univoco.

Per rispondere alla tua prima domanda, il modo in cui carichi un modulo dipende dal punto di ingresso del modulo e dal parametro principale di package.json .

Supponiamo che tu abbia la seguente struttura di file:

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

Senza parametro principale nel package.json , è necessario caricare il modulo dando il punto di ingresso del modulo: require('my-npm-module/lib/module.js').

Se si imposta il package.json parametro principale come segue "main": "lib/module.js", si sarà in grado di caricare il modulo in questo modo: require('my-npm-module').

Se hai ad esempio nel tuo package.jsonfile:

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

lib/entry.js sarà il punto di accesso principale al tuo pacchetto.

Quando si chiama

require('zig-zag');

nel nodo, lib/entry.jssarà il file effettivo richiesto.

Una funzione importante del maintasto è che fornisce il percorso per il punto di ingresso. Questo è molto utile quando si lavora con nodemon. Se lavori connodemon e definisci la mainchiave nel tuo package.jsoncome diciamo "main": "./src/server/app.js", allora puoi semplicemente accendere il server digitando nodemonla CLI con root come pwd invece di nodemon ./src/server/app.js .

Per quanto ne so, è il punto di accesso principale al pacchetto del nodo (libreria) per npm. È necessario solo se il progetto npm diventa un pacchetto nodo (libreria) che può essere installato da npm da altri.

Supponiamo che tu abbia una libreria con una cartella build /, dist / o lib /. In questa cartella, hai ottenuto il seguente file compilato per la tua libreria:

-lib/
--bundle.js

Quindi nel tuo package.json , dici a npm come accedere alla libreria (pacchetto nodo):

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

Dopo aver installato il pacchetto del nodo con npm nel progetto JS, è possibile importare funzionalità dal file bundle.js in bundle :

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

Questo vale anche quando si utilizza la suddivisione del codice (ad es. Webpack) per la propria libreria. Ad esempio, questo webpack.config.js utilizza il codice che divide il progetto in più bundle anziché in uno.

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',
  },
  ...
}

Tuttavia, definiresti un punto di accesso principale alla tua libreria nel tuo package.json :

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

Quindi, quando si utilizza la libreria, è possibile importare i file dal punto di ingresso principale:

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

Tuttavia, puoi anche bypassare il punto di ingresso principale da package.json e importare i bundle suddivisi in codice:

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

Dopotutto, la proprietà principale in package.json punta solo al file del punto di ingresso principale della libreria.

Per OpenShift, ottieni solo una coppia PORT e IP a cui associare (per applicazione). Sembra che dovresti essere in grado di servire entrambi i servizi da una singola istanza nodejs aggiungendo route interne per ciascun endpoint del servizio.

Ho alcune informazioni su come OpenShift utilizza il package.json del progetto per avviare l'applicazione qui: https://www.openshift.com/blogs/run-your-nodejs-projects-on-openshift-in-two-simple-steps #package_json

Basti pensare ad esso come al "punto di partenza".

In un senso di programmazione orientata agli oggetti, diciamo C #, è init () o il costruttore della classe di oggetti, ecco cosa significava "punto di ingresso".

Per esempio

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

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