Ajouter des métadonnées ou une configuration personnalisées au fichier package.json, est-il valide ?

Question

J'ai vu (je ne me souviens plus où) un fichier package.json avec des clés personnalisées commençant par un underscore :

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

Vous avez le droit de faire ça ? Est-il encore valable ? Si cela est autorisé, existe-t-il une documentation sur les règles ?

Gracias.

Answer 1

en résumé :

• Oui, vous êtes autorisé pour ajouter des entrées personnalisées à package.json .
• Choisissez un nom de clé :
  • pas encore défini (détails ci-dessous)
  • non réservé pour une utilisation ultérieure (détails ci-dessous)
  • éviter préfixes _ y $
  • et de préférence utiliser un simple clé de niveau supérieur dans laquelle nid vos entrées personnalisées .

Par exemple, si vous possédez un domaine example.org vous pouvez enregistrer un random comme suit, à l'intérieur d'une clé de premier niveau en notation inverse de nom de domaine avec _ substitué à . et, le cas échéant, - (voir les commentaires) (par exemple, org_example ):

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

Pour lire de telles propriétés personnalisées, utilisez la technique suivante :

require("./package.json").org_example.random // -> true

---

npm 's package.json Le format de fichier est en grande partie conforme à la norme Spécification des paquets CommonJS :

• des clés qui npm utilise actuellement : https://docs.npmjs.com/files/package.json
• clés définies dans la spécification : http://wiki.commonjs.org/wiki/Packages/1.1

Quant à choix de clés personn personn personn personn personn personnalisées : le Spécification des paquets CommonJS (c'est moi qui souligne) :

Les champs suivants sont réservé para futur l'expansion : build , default , email , external , files , imports , maintainer , paths , platform , require , summary , test , using , downloads , uid .

Les extensions de la spécification du descripteur de paquet doivent s'efforcer d'éviter les collisions pour les futurs noms standard en espaçant les noms de leurs propriétés avec des noms inoffensifs qui n'ont pas de signification pertinente pour la gestion générale des paquets. .

Les champs suivants sont réservé aux registres de paquets à utiliser à leur discrétion : id , type . Tous les sites les propriétés commençant par _ o $ sont également réservés que les registres de paquets peuvent utiliser à leur gré.

Answer 2

Compte tenu de la nature de JSON et de cette déclaration du Documentation de Nodejitsu Je ne vois rien de mal à cela.

NPM lui-même n'est conscient que de deux dans le fichier package.json :

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

NPM se préoccupe également de quelques champs répertoriés aquí . Tant que le JSON est valide et qu'il n'interfère pas avec Node.js ou NPM, tout devrait être correct et valide.

La conscience que Node a des fichiers package.json semble s'étendre à l'espace de travail de l'utilisateur. principal champ. Réf.

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

S'il se trouvait dans un dossier ./some-library, alors require('./some-library') tenterait de charger le fichier ./some-library/lib/some-library.js.

C'est l'étendue de la sensibilisation de Node aux fichiers package.json.

Pour éviter d'éventuels conflits, vous devez préfixer vos clés par un caractère ou un mot. Il n'est pas recommandé d'utiliser un trait de soulignement (_) ou le signe dollar ($), car il s'agit de préfixes de caractères réservés, mais d'autres choix sont possibles.