Parámetro principal de Node.js package.json

Ya he hecho bastante búsqueda. Sin embargo, todavía tengo dudas sobre el parámetro principal en package.json de Node.js.

1. ¿Cómo ayudaría completar este campo? Preguntando de otra manera, ¿puedo iniciar el módulo en un estilo diferente si este campo se presenta?
2. ¿Puedo completar más de un script en el parámetro principal? En caso afirmativo, ¿se iniciarían como dos hilos? Si no, ¿cómo puedo iniciar dos scripts en un módulo y hacer que se ejecuten en paralelo?

Sé que la segunda pregunta es bastante extraña. Es porque he alojado una aplicación Node.js en OpenShift pero la aplicación consta de dos componentes principales. Uno de ellos es una API REST y otro un servicio de entrega de notificaciones.

Me temo que el proceso de entrega de notificaciones bloquearía la API REST si se implementaran como un solo hilo. Sin embargo, tienen que conectarse al mismo cartucho MongoDB. Además, me gustaría guardar un engranaje si ambos componentes podrían estar sirviendo en el mismo engranaje si es posible.

Cualquier sugerencia es bienvenida.

De la documentación de npm :

El campo principal es una ID de módulo que es el punto de entrada principal a su programa. Es decir, si su paquete se llama foo, y un usuario lo instala y luego requiere ("foo"), se devolverá el objeto de exportación del módulo principal.

Este debería ser un ID de módulo relativo a la raíz de la carpeta de su paquete.

Para la mayoría de los módulos, tiene más sentido tener un script principal y, a menudo, no mucho más.

Para abreviar:

1. Solo necesita un mainparámetro en su package.jsonsi el punto de entrada a su paquete difiere de index.jssu carpeta raíz. Por ejemplo, las personas a menudo ponen el punto de entrada lib/index.jso lib/<packagename>.js, en este caso, el script correspondiente debe describirse como mainen package.json.
2. No puede tener dos scripts como main, simplemente porque el punto de entrada require('yourpackagename')debe definirse sin ambigüedades.

Para responder a su primera pregunta, la forma en que carga un módulo depende del punto de entrada del módulo y del parámetro principal de package.json .

Digamos que tiene la siguiente estructura de archivos:

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

Sin principal parámetro en el package.json , tiene que cargar el módulo, dando el punto de entrada del módulo: require('my-npm-module/lib/module.js').

Si se establece la package.json principal parámetro de la siguiente manera "main": "lib/module.js", usted será capaz de cargar el módulo de esta manera: require('my-npm-module').

Si tiene por ejemplo en su package.jsonarchivo:

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

lib/entry.js será el principal punto de entrada a su paquete.

Cuando llame

require('zig-zag');

en el nodo, lib/entry.jsserá el archivo real que se requiere.

Una función importante de la mainclave es que proporciona el camino para su punto de entrada. Esto es muy útil cuando se trabaja con nodemon. Si trabaja con nodemony define la mainclave en su package.jsoncomo digamos "main": "./src/server/app.js", entonces simplemente puede poner en marcha el servidor escribiendo nodemonla CLI con root como pwd en lugar de nodemon ./src/server/app.js .

Hasta donde sé, es el punto de entrada principal a su paquete de nodos (biblioteca) para npm. Solo es necesario si su proyecto npm se convierte en un paquete de nodo (biblioteca) que otros pueden instalar a través de npm.

Digamos que tiene una biblioteca con una carpeta build /, dist / o lib /. En esta carpeta, obtuvo el siguiente archivo compilado para su biblioteca:

-lib/
--bundle.js

Luego, en su package.json , le dice a npm cómo acceder a la biblioteca (paquete de nodos):

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

Después de instalar el paquete de nodo con npm en su proyecto JS, puede importar funcionalidades desde su archivo bundle.js incluido :

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

Esto también es válido cuando se utiliza la división de código (por ejemplo, Webpack) para su biblioteca. Por ejemplo, este webpack.config.js hace uso del código que divide el proyecto en múltiples paquetes en lugar de 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',
  },
  ...
}

Aún así, definiría un punto de entrada principal a su biblioteca en su package.json :

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

Luego, cuando use la biblioteca, puede importar sus archivos desde su punto de entrada principal:

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

Sin embargo, también puede omitir el punto de entrada principal desde package.json e importar los paquetes divididos de código:

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

Después de todo, la propiedad principal en su package.json solo apunta a su archivo de punto de entrada principal de su biblioteca.

Para OpenShift, solo obtienes un puerto y un par de IP para vincular (por aplicación). Parece que debería poder servir ambos servicios desde una sola instancia de nodejs agregando rutas internas para cada punto final de servicio.

Tengo información sobre cómo OpenShift utiliza el paquete de su proyecto. Json para iniciar su aplicación aquí: https://www.openshift.com/blogs/run-your-nodejs-projects-on-openshift-in-two-simple-steps #package_json

Solo piense en ello como el "punto de partida".

En un sentido de programación orientada a objetos, digamos C #, es el init () o el constructor de la clase de objeto, eso es lo que significa "punto de entrada".

Por ejemplo

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

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