Parâmetro principal do Node.js package.json

Eu já fiz algumas pesquisas. No entanto, ainda há dúvidas sobre o parâmetro principal no package.json do Node.js.

1. Como o preenchimento desse campo ajuda? Perguntando de outra maneira, posso iniciar o módulo em um estilo diferente se esse campo aparecer?
2. Posso ter mais de um script sendo preenchido no parâmetro principal? Se sim, eles seriam iniciados como dois threads? Se não, como posso iniciar dois scripts em um módulo e executá-los em paralelo?

Eu sei que a segunda pergunta é bastante estranha. É porque eu hospedei um aplicativo Node.js. no OpenShift, mas o aplicativo consiste em dois componentes principais. Uma sendo uma API REST e outra sendo um serviço de entrega de notificações.

Receio que o processo de entrega de notificações bloqueie a API REST se eles forem implementados como um único encadeamento. No entanto, eles precisam se conectar ao mesmo cartucho MongoDB. Além disso, eu gostaria de salvar uma engrenagem, se ambos os componentes pudessem servir na mesma engrenagem, se possível.

Todas as sugestões são bem-vindas.

Na documentação do npm :

O campo principal é um ID do módulo que é o principal ponto de entrada do seu programa. Ou seja, se o seu pacote for nomeado foo, e um usuário o instalar e exigir ("foo"), o objeto de exportação do módulo principal será retornado.

Este deve ser um ID de módulo relativo à raiz da sua pasta do pacote.

Para a maioria dos módulos, faz mais sentido ter um script principal e muitas vezes não muito mais.

Para resumir:

1. Você só precisa de um mainparâmetro no seu package.jsonse o ponto de entrada do seu pacote for diferente da index.jspasta raiz. Por exemplo, as pessoas geralmente colocam o ponto de entrada em lib/index.jsou lib/<packagename>.js, nesse caso, o script correspondente deve ser descrito como mainem package.json.
2. Você não pode ter dois scripts como mainsimplesmente porque o ponto de entrada require('yourpackagename')deve ser definido sem ambiguidade.

Para responder sua primeira pergunta, a maneira como você carrega um módulo depende do ponto de entrada do módulo e do parâmetro principal do package.json .

Digamos que você tenha a seguinte estrutura de arquivos:

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

Sem parâmetro principal no package.json , você tem que carregar o módulo, dando o ponto de entrada do módulo: require('my-npm-module/lib/module.js').

Se você definir o package.json principal parâmetro da seguinte forma "main": "lib/module.js", você será capaz de carregar o módulo desta forma: require('my-npm-module').

Se você tem, por exemplo, em seu package.jsonarquivo:

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

lib/entry.js será o principal ponto de entrada do seu pacote.

Ao ligar

require('zig-zag');

no nó, lib/entry.jsserá o arquivo real necessário.

Uma função importante da mainchave é que ela fornece o caminho para o seu ponto de entrada. Isso é muito útil ao trabalhar com nodemon. Se você trabalha nodemone define a mainchave no seu package.jsoncomo "main": "./src/server/app.js", digamos , você pode simplesmente ativar o servidor digitando nodemonna CLI com root como pwd em vez de nodemon ./src/server/app.js .

Até onde eu sei, é o principal ponto de entrada do pacote de nós (biblioteca) para o npm. Só é necessário se o seu projeto npm se tornar um pacote de nó (biblioteca) que pode ser instalado via npm por outras pessoas.

Digamos que você tenha uma biblioteca com uma pasta build /, dist / ou lib /. Nesta pasta, você obteve o seguinte arquivo compilado para sua biblioteca:

-lib/
--bundle.js

Então, em seu package.json , você informa ao npm como acessar a biblioteca (pacote de nós):

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

Após instalar o pacote do nó com npm no seu projeto JS, é possível importar funcionalidades do seu arquivo bundle.js empacotado :

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

Isso também se aplica ao usar o Code Splitting (por exemplo, Webpack) para sua biblioteca. Por exemplo, este webpack.config.js utiliza o código que divide o projeto em vários pacotes configuráveis em vez de um.

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

Ainda assim, você definiria um ponto de entrada principal para sua biblioteca no seu package.json :

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

Então, ao usar a biblioteca, você pode importar seus arquivos do seu ponto de entrada principal:

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

No entanto, você também pode ignorar o ponto de entrada principal do package.json e importar os pacotes configuráveis ​​divididos por código:

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

Afinal, a propriedade principal em seu package.json aponta apenas para o arquivo de ponto de entrada principal da sua biblioteca.

Para o OpenShift, você obtém apenas um par PORT e IP ao qual vincular (por aplicativo). Parece que você deve poder atender os dois serviços a partir de uma única instância do nodejs adicionando rotas internas para cada terminal de serviço.

Tenho algumas informações sobre como o OpenShift usa o package.json do seu projeto para iniciar seu aplicativo aqui: https://www.openshift.com/blogs/run-your-nodejs-projects-on-openshift-in-two-simple-steps #package_json

Pense nisso como o "ponto de partida".

Em um sentido de programação orientada a objetos, digamos C #, é o init () ou o construtor da classe de objetos, é isso que significa "ponto de entrada".

Por exemplo

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

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