read-package-json
Advanced tools
The thing npm uses to read package.json files with semantics and defaults and validation
The read-package-json npm package is used to read and parse package.json files in a way that npm also does. It normalizes some of the data and can handle different file encodings, comments, and trailing commas.
Read and parse package.json
This feature reads and parses the package.json file located at the specified path. It handles errors and outputs the package data.
const readPackageJson = require('read-package-json');
readPackageJson('/path/to/package.json', console.error, false, function (er, data) {
if (er) {
console.error("There was an error reading the file")
return
}
console.log('The package data is', data)
})Normalize package data
This feature reads the package.json file and normalizes its data to ensure consistency in the structure and values of the package's metadata.
const readPackageJson = require('read-package-json');
readPackageJson('/path/to/package.json', console.error, true, function (er, data) {
if (er) {
console.error("There was an error reading the file")
return
}
console.log('The normalized package data is', data)
})read-pkg is similar to read-package-json as it reads and parses package.json files. It returns a promise and uses the 'normalize-package-data' library to normalize the package data. It is a higher-level wrapper around 'load-json-file' and 'normalize-package-data'.
load-json-file is a package that reads and parses JSON files. It does not specifically target package.json files, but it can be used for that purpose. It returns a promise and throws more descriptive errors than the default JSON.parse.
normalize-package-data is a package that normalizes package metadata, similar to one of the features of read-package-json. It does not read the package.json file itself but is often used in conjunction with other packages that do.
This is the thing that npm uses to read package.json files. It validates some stuff, and loads some default things.
It keeps a cache of the files you've read, so that you don't end up reading the same package.json file multiple times.
Note that if you just want to see what's literally in the package.json
file, you can usually do var data = require('some-module/package.json').
This module is basically only needed by npm, but it's handy to see what npm will see when it looks at your package.
var readJson = require('read-package-json')
// readJson(filename, [logFunction=noop], [strict=false], cb)
readJson('/path/to/package.json', console.error, false, function (er, data) {
if (er) {
console.error("There was an error reading the file")
return
}
console.error('the package data is', data)
});
file {String} The path to the package.json filelogFn {Function} Function to handle logging. Defaults to a noop.strict {Boolean} True to enforce SemVer 2.0 version strings, and
other strict requirements.cb {Function} Gets called with (er, data), as is The Node Way.Reads the JSON file and does the things.
package.json FieldsSee man 5 package.json or npm help json.
By default this is a reference to the npmlog module. But if that
module can't be found, then it'll be set to just a dummy thing that does
nothing.
Replace with your own {log,warn,error} object for fun loggy time.
Run all the extra stuff relative to the file, with the parsed data.
Modifies the data as it does stuff. Calls the cb when it's done.
Array of functions that are called by extras. Each one receives the
arguments fn(file, data, cb) and is expected to call cb(er, data)
when done or when an error occurs.
Order is indeterminate, so each function should be completely independent.
Mix and match!
package.jsonSome other files have an effect on the resulting data object, in the following ways:
README?(.*)If there is a README or README.* file present, then npm will attach
a readme field to the data with the contents of this file.
Owing to the fact that roughly 100% of existing node modules have Markdown README files, it will generally be assumed to be Markdown, regardless of the extension. Please plan accordingly.
server.jsIf there is a server.js file, and there is not already a
scripts.start field, then scripts.start will be set to node server.js.
AUTHORSIf there is not already a contributors field, then the contributors
field will be set to the contents of the AUTHORS file, split by lines,
and parsed.
bindings.gypIf a bindings.gyp file exists, and there is not already a
scripts.install field, then the scripts.install field will be set to
node-gyp rebuild.
index.jsIf the json file does not exist, but there is a index.js file
present instead, and that file has a package comment, then it will try
to parse the package comment, and use that as the data instead.
A package comment looks like this:
/**package
* { "name": "my-bare-module"
* , "version": "1.2.3"
* , "description": "etc...." }
**/
// or...
/**package
{ "name": "my-bare-module"
, "version": "1.2.3"
, "description": "etc...." }
**/
The important thing is that it starts with /**package, and ends with
**/. If the package.json file exists, then the index.js is not
parsed.
{directories.man}/*.[0-9]If there is not already a man field defined as an array of files or a
single file, and
there is a directories.man field defined, then that directory will
be searched for manpages.
Any valid manpages found in that directory will be assigned to the man
array, and installed in the appropriate man directory at package install
time, when installed globally on a Unix system.
{directories.bin}/*If there is not already a bin field defined as a string filename or a
hash of <name> : <filename> pairs, then the directories.bin
directory will be searched and all the files within it will be linked as
executables at install time.
When installing locally, npm links bins into node_modules/.bin, which
is in the PATH environ when npm runs scripts. When
installing globally, they are linked into {prefix}/bin, which is
presumably in the PATH environment variable.
types fieldIf you do not have a types field, then it will check if a
corresponding *.d.ts file exists for your package entry file and add
it to the package.json.
7.0.1 (2024-05-04)
fae3210 #223 bump @npmcli/template-oss to 4.22.0 (@lukekarrys)c73cf0d #190 use npm 9 for CI (#190) (@wraithgar)1f477a8 #189 Fix out-of-order ChangeLog entry (#189) (@daniel-santos)153cfda #223 postinstall for dependabot template-oss PR (@lukekarrys)cd2962f #221 bump @npmcli/template-oss from 4.21.3 to 4.21.4 (@dependabot[bot])FAQs
The thing npm uses to read package.json files with semantics and defaults and validation
The npm package read-package-json receives a total of 4,787,864 weekly downloads. As such, read-package-json popularity was classified as popular.
We found that read-package-json demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 5 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Research
Security News
Socket researchers uncover a malicious npm package posing as a tool for detecting vulnerabilities in Etherium smart contracts.
Security News
Research
A supply chain attack on Rspack's npm packages injected cryptomining malware, potentially impacting thousands of developers.
Research
Security News
Socket researchers discovered a malware campaign on npm delivering the Skuld infostealer via typosquatted packages, exposing sensitive data.