Agregar metadatos o configuraciones personalizadas a package.json, ¿es válido?

Question

que he visto (no recuerdo dónde) un archivo package.json con teclas personalizadas a partir de un guión:

{ 
    "name": "application-name" 
    , "version": "0.0.1" 
    , "private": true 
    , "dependencies": { 
     "express": "2.4.7" 
    , "jade": ">= 0.0.1" 
    } 
    , "_random": true 
} 

¿Se le permite hacer esto? ¿Sigue siendo válido? Si esto está permitido, ¿hay alguna documentación sobre las reglas?

Gracias!

Answer 1

tl; dr:

• Sí, se le permite añadir entradas personalizadas a package.json.
• elegir un nombre clave:
  • no se ha definido (detalles a continuación)
  • no reservados para uso futuro (detalles a continuación)
  • evitar prefijos _ y $
  • y preferiblemente use un solo top-lev la clave en la que a nido sus entradas personalizadas.

P. ej, Si es el propietario del dominio example.org, podría almacenar una clave personalizada random de la siguiente manera, dentro de una clave de nivel superior en nombre-dominio-inverso notación con _ sustituido por . y, en su caso, -^{(ver comentarios)} (por ejemplo, org_example):

{ 
    "name": "application-name" 
    , "version": "0.0.1" 
    , "private": true 
    , "dependencies": { 
     "express": "2.4.7" 
    , "jade": ">= 0.0.1" 
    } 
    , "org_example": { 
     "random": true 
    } 
} 

package.json formato de archivo

---

npm 's cumple con la mayoría CommonJS package specification:

• claves que npm utiliza actualmente: https://www.npmjs.org/doc/files/package.json.html
• claves definidas en la especificación: http://wiki.commonjs.org/wiki/Packages/1.1

En cuanto a la elección de teclas personalizadas: los CommonJS package specification estados (el énfasis es mío):

El siguiente campo ds son reservada parafutura expansión: build, default, email, external, files, imports, maintainer, paths, platform, require, summary, test, using, downloads, uid.

Las extensiones de la especificación del descriptor de paquete deben esforzarse para evitar colisiones para futuros nombres estándar espaciando sus propiedades con nombres inocuos que no tienen significados relevantes para la administración general de paquetes.

Los siguientes campos se reservan para paquete de registros utilizar a su discreción: id, type. Todas las propiedades que comienzan con _ o $ también están reservadas para registros de paquetes para usar a su discreción.

Answer 2

Dada la naturaleza de JSON y esta declaración del Nodejitsu documentation, no veo nada de malo en eso.

NPM sí sólo es consciente de dos campos en la package.json:

{ 
    "name" : "barebones", 
    "version" : "0.0.0", 
} 

NGP también se preocupa por un par de campos en la lista here. Por lo tanto, siempre que sea JSON válido y no interfiera con Node.js o NPM, todo debería estar bien y ser válido.

El conocimiento de nodo de los archivos package.json parece extenderse al campo principal. Ref.

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

Si esto fue en una carpeta en ./some-library, entonces require ('./ alguna biblioteca') sería intentar cargar ./some-library/lib/some- library.js.

Este es el grado de conocimiento de Node de los archivos package.json.

Para evitar posibles conflictos, debe anteponer sus teclas con algún carácter o palabra. Un guión bajo es una variante común.