Gathering detailed insights and metrics for normalize-package-data
Gathering detailed insights and metrics for normalize-package-data
Gathering detailed insights and metrics for normalize-package-data
Gathering detailed insights and metrics for normalize-package-data
@types/normalize-package-data
TypeScript definitions for normalize-package-data
read-pkg
Read a package.json file
normalize-path
Normalize slashes in a file path to be posix/unix-like forward slashes. Also condenses repeat slashes to a single slash and removes and trailing slashes, unless disabled.
normalize-url
Normalize a URL
normalizes package metadata, typically found in package.json file.
npm install normalize-package-data
Module System
Min. Node Version
Typescript Support
Node Version
NPM Version
197 Stars
344 Commits
48 Forks
31 Watching
2 Branches
104 Contributors
Updated on 27 Nov 2024
Minified
Minified + Gzipped
JavaScript (100%)
Cumulative downloads
Total Downloads
Last day
-1%
9,823,987
Compared to previous day
Last week
5.4%
54,077,495
Compared to previous week
Last month
23.2%
208,472,181
Compared to previous month
Last year
11.8%
2,091,308,952
Compared to previous year
3
3
normalize-package-data exports a function that normalizes package metadata. This data is typically found in a package.json file, but in principle could come from any source - for example the npm registry.
normalize-package-data is used by read-package-json to normalize the data it reads from a package.json file. In turn, read-package-json is used by npm and various npm-related tools.
npm install normalize-package-data
Basic usage is really simple. You call the function that normalize-package-data exports. Let's call it normalizeData
.
1normalizeData = require('normalize-package-data') 2packageData = require("./package.json") 3normalizeData(packageData) 4// packageData is now normalized
You may activate strict validation by passing true as the second argument.
1normalizeData = require('normalize-package-data') 2packageData = require("./package.json") 3normalizeData(packageData, true) 4// packageData is now normalized
If strict mode is activated, only Semver 2.0 version strings are accepted. Otherwise, Semver 1.0 strings are accepted as well. Packages must have a name, and the name field must not have contain leading or trailing whitespace.
Optionally, you may pass a "warning" function. It gets called whenever the normalizeData
function encounters something that doesn't look right. It indicates less than perfect input data.
1normalizeData = require('normalize-package-data') 2packageData = require("./package.json") 3warnFn = function(msg) { console.error(msg) } 4normalizeData(packageData, warnFn) 5// packageData is now normalized. Any number of warnings may have been logged.
You may combine strict validation with warnings by passing true
as the second argument, and warnFn
as third.
When private
field is set to true
, warnings will be suppressed.
If the supplied data has an invalid name or version field, normalizeData
will throw an error. Depending on where you call normalizeData
, you may want to catch these errors so can pass them to a callback.
name
field gets trimmed (unless in strict mode).version
field gets cleaned by semver.clean
. See documentation for the semver module.name
and/or version
fields are missing, they are set to empty strings.files
field is not an array, it will be removed.bin
field is a string, then bin
field will become an object with name
set to the value of the name
field, and bin
set to the original string value.man
field is a string, it will become an array with the original string as its sole member.keywords
field is string, it is considered to be a list of keywords separated by one or more white-space characters. It gets converted to an array by splitting on \s+
.author
, maintainers
, contributors
) get converted into objects with name, email and url properties.bundledDependencies
field (a typo) exists and bundleDependencies
field does not, bundledDependencies
will get renamed to bundleDependencies
.dependencies
, devDependencies
, optionalDependencies
) is a string, it gets converted into an object with familiar name=>value
pairs.optionalDependencies
get added to dependencies
. The optionalDependencies
array is left untouched.org/proj
, github:org/proj
, bitbucket:org/proj
, gitlab:org/proj
, gist:docid
) will have the shortcut left in place. (In the case of github, the org/proj
form will be expanded to github:org/proj
.) THIS MARKS A BREAKING CHANGE FROM V1, where the shortcut was previously expanded to a URL.description
field does not exist, but readme
field does, then (more or less) the first paragraph of text that's found in the readme is taken as value for description
.repository
field is a string, it will become an object with url
set to the original string value, and type
set to "git"
.repository.url
is not a valid url, but in the style of "[owner-name]/[repo-name]", repository.url
will be set to git+https://github.com/[owner-name]/[repo-name].gitbugs
field is a string, the value of bugs
field is changed into an object with url
set to the original string value.bugs
field does not exist, but repository
field points to a repository hosted on GitHub, the value of the bugs
field gets set to an url in the form of https://github.com/[owner-name]/[repo-name]/issues . If the repository field points to a GitHub Gist repo url, the associated http url is chosen.bugs
field is an object, the resulting value only has email and url properties. If email and url properties are not strings, they are ignored. If no valid values for either email or url is found, bugs field will be removed.homepage
field is not a string, it will be removed.homepage
field does not specify a protocol, then http is assumed. For example, myproject.org
will be changed to http://myproject.org
.homepage
field does not exist, but repository
field points to a repository hosted on GitHub, the value of the homepage
field gets set to an url in the form of https://github.com/[owner-name]/[repo-name]#readme . If the repository field points to a GitHub Gist repo url, the associated http url is chosen.If name
field is given, the value of the name field must be a string. The string may not:
/@\s+%
node_modules
or favicon.ico
(case doesn't matter).If version
field is given, the value of the version field must be a valid semver string, as determined by the semver.valid
method. See documentation for the semver module.
The license
/licence
field should be a valid SPDX license expression or one of the special values allowed by validate-npm-package-license. See documentation for the license field in package.json.
This package contains code based on read-package-json written by Isaac Z. Schlueter. Used with permission.
normalize-package-data is released under the BSD 2-Clause License. Copyright (c) 2013 Meryn Stol
No vulnerabilities found.
Reason
security policy file detected
Details
Reason
all changesets reviewed
Reason
no binaries found in the repo
Reason
no dangerous workflow patterns detected
Reason
0 existing vulnerabilities detected
Reason
license file detected
Details
Reason
SAST tool detected but not run on all commits
Details
Reason
9 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 7
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
dependency not pinned by hash detected -- score normalized to 0
Details
Reason
detected GitHub workflow tokens with excessive permissions
Details
Reason
project is not fuzzed
Details
Score
Last Scanned on 2024-11-18
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More