Node.js paramètre principal package.json

J'ai déjà fait pas mal de recherches. Cependant, j'ai toujours des doutes sur le paramètre principal de package.json de Node.js.

1. Comment le remplissage de ce champ aiderait-il? En demandant d'une autre manière, puis-je démarrer le module dans un style différent si ce champ est présent?
2. Puis-je avoir plusieurs scripts remplis dans le paramètre principal? Si oui, seraient-ils lancés comme deux fils? Si non, comment puis-je démarrer deux scripts dans un module et les faire exécuter en parallèle?

Je sais que la deuxième question est assez étrange. C'est parce que j'ai hébergé une application Node.js sur OpenShift mais l'application se compose de deux composants principaux. L'un étant une API REST et l'autre un service de notification.

J'ai peur que le processus de livraison de notification bloque l'API REST si elles étaient implémentées en tant que thread unique. Cependant, ils doivent se connecter à la même cartouche MongoDB. De plus, je voudrais économiser un engrenage si les deux composants pouvaient servir dans le même engrenage si possible.

Toutes les suggestions sont les bienvenues.

De la documentation npm :

Le champ principal est un ID de module qui est le point d'entrée principal de votre programme. Autrement dit, si votre paquet est nommé foo, et qu'un utilisateur l'installe, puis requiert ("foo"), alors l'objet d'exportation de votre module principal sera retourné.

Il doit s'agir d'un ID de module relatif à la racine de votre dossier de package.

Pour la plupart des modules, il est plus judicieux d'avoir un script principal et souvent pas grand-chose d'autre.

Pour faire court:

1. Vous n'avez besoin d'un mainparamètre dans votre que package.jsonsi le point d'entrée de votre package diffère de index.jsson dossier racine. Par exemple, les gens mettent souvent le point d'entrée vers lib/index.jsou lib/<packagename>.js, dans ce cas, le script correspondant doit être décrit comme maindans package.json.
2. Vous ne pouvez pas avoir deux scripts comme main, simplement parce que le point d'entrée require('yourpackagename')doit être défini sans ambiguïté.

Pour répondre à votre première question, la façon dont vous chargez un module dépend du point d'entrée du module et du paramètre principal du package.json .

Disons que vous avez la structure de fichiers suivante:

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

Sans paramètre principal dans le package.json , vous devez charger le module en donnant le point d'entrée du module: require('my-npm-module/lib/module.js').

Si vous définissez le package.json paramètre principal comme suit "main": "lib/module.js", vous serez en mesure de charger le module ainsi: require('my-npm-module').

Si vous avez par exemple dans votre package.jsondossier:

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

lib/entry.js sera le principal point d'entrée de votre colis.

Lors de l'appel

require('zig-zag');

dans node, lib/entry.jssera le fichier réel requis.

Une fonction importante de la mainclé est qu'elle fournit le chemin de votre point d'entrée. Ceci est très utile lorsque vous travaillez avec nodemon. Si vous travaillez avec nodemonet que vous définissez la mainclé dans votre package.jsoncomme disons "main": "./src/server/app.js", vous pouvez simplement lancer le serveur en tapant nodemondans la CLI avec root comme pwd au lieu de nodemon ./src/server/app.js .

Autant que je sache, c'est le point d'entrée principal de votre package de nœuds (bibliothèque) pour npm. Ce n'est nécessaire que si votre projet npm devient un package de nœuds (bibliothèque) qui peut être installé via npm par d'autres.

Disons que vous avez une bibliothèque avec un dossier build /, dist / ou lib /. Dans ce dossier, vous avez le fichier compilé suivant pour votre bibliothèque:

-lib/
--bundle.js

Ensuite, dans votre package.json , vous indiquez à npm comment accéder à la bibliothèque (package de nœuds):

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

Après avoir installé le package de nœuds avec npm dans votre projet JS, vous pouvez importer des fonctionnalités à partir de votre fichier bundle.js fourni :

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

Cela est également vrai lorsque vous utilisez le partage de code (par exemple, Webpack) pour votre bibliothèque. Par exemple, ce webpack.config.js utilise du code divisant le projet en plusieurs bundles au lieu d'un.

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

Néanmoins, vous définiriez un point d'entrée principal vers votre bibliothèque dans votre package.json :

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

Ensuite, lors de l'utilisation de la bibliothèque, vous pouvez importer vos fichiers depuis votre point d'entrée principal:

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

Cependant, vous pouvez également contourner le point d'entrée principal du package.json et importer les bundles fractionnés de code:

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

Après tout, la propriété principale de votre package.json pointe uniquement vers votre fichier de point d'entrée principal de votre bibliothèque.

Pour OpenShift, vous n'obtenez qu'une seule paire PORT et IP à laquelle se lier (par application). Il semble que vous devriez être en mesure de servir les deux services à partir d'une seule instance de nodejs en ajoutant des routes internes pour chaque point de terminaison de service.

J'ai quelques informations sur la façon dont OpenShift utilise le package.json de votre projet pour démarrer votre application ici: https://www.openshift.com/blogs/run-your-nodejs-projects-on-openshift-in-two-simple-steps #package_json

Pensez-y simplement comme le "point de départ".

Dans un sens de la programmation orientée objet, disons C #, c'est l'init () ou le constructeur de la classe d'objets, c'est ce que signifiait «point d'entrée».

Par exemple

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

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