Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Add custom metadata or config to package.json, is it valid?

Tags:

node.js

I have seen (don't remember where) a package.json file with custom keys starting with an underscore:

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

Are you allowed to do this? Is it still valid? If this is allowed, is there any documentation on the rules?

Thanks!

like image 564
Lance Avatar asked Apr 08 '12 19:04

Lance


People also ask

Is it good to commit package lock json?

json intact. It is highly recommended you commit the generated package lock to source control: this will allow anyone else on your team, your deployments, your CI/continuous integration, and anyone else who runs npm install in your package source to get the exact same dependency tree that you were developing on.

Which fields are the most important in your package json?

name — This is the most important and required field in the package. json file. This should represent the name of the project.

What should I put in package json?

A package. json file must contain "name" and "version" fields. The "name" field contains your package's name, and must be lowercase and one word, and may contain hyphens and underscores. The "version" field must be in the form x.x.x and follow the semantic versioning guidelines.

Can I modify package lock json?

A key point here is that install can alter package-lock. json if it registers that it's outdated. For example, if someone manually alters package. json — say, for example, they remove a package since it's just a matter of removing a single line — the next time that someone runs npm install , it will alter package-lock.


2 Answers

tl;dr:

  • Yes, you're allowed to add custom entries to package.json.
  • Choose a key name:
    • not already defined (details below)
    • not reserved for future use (details below)
    • avoid prefixes _ and $
    • and preferably use a single top-level key in which to nest your custom entries.

E.g., if you own domain example.org, you could store a custom random key as follows, inside a top-level key in reverse-domain-name notation with _ substituted for . and, if applicable, -(see comments) (e.g., org_example):

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

To read such custom properties, use the following technique:

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

npm's package.json file format mostly complies with the CommonJS package specification:

  • keys that npm currently uses: https://docs.npmjs.com/files/package.json
  • keys defined in the spec: http://wiki.commonjs.org/wiki/Packages/1.1

As for choosing custom keys: the CommonJS package specification states (emphasis mine):

The following fields are reserved for future expansion: build, default, email, external, files, imports, maintainer, paths, platform, require, summary, test, using, downloads, uid.

Extensions to the package descriptor specification should strive to avoid collisions for future standard names by name-spacing their properties with innocuous names that do not have meanings relevant to general package management.

The following fields are reserved for package registries to use at their discretion: id, type. All properties beginning with _ or $ are also reserved for package registries to use at their discretion.

like image 127
mklement0 Avatar answered Oct 02 '22 12:10

mklement0


Given the nature of JSON and this statement from the Nodejitsu documentation I don't see anything wrong with that.

NPM itself is only aware of two fields in the package.json:

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

NPM also cares about a couple of fields listed here. So as long as it is valid JSON and doesn't interfere with Node.js or NPM everything should be alright and valid.

Node's awareness of package.json files seems extends to the main field. Ref.

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

If this was in a folder at ./some-library, then require('./some-library') would attempt to load ./some-library/lib/some-library.js.

This is the extent of Node's awareness of package.json files.

To avoid possible conflicts you should prefixing your keys with some character or word. It is not recommended to use an underscore (_) or dollar sign ($) as those are reserved character prefixes, but other choices are viable.

like image 39
Octavian A. Damiean Avatar answered Oct 02 '22 12:10

Octavian A. Damiean