https://github.com/isaacs/npm/blob/master/doc/files/package.json.md#bin

{ "name": "my-program"
, "version": "1.2.5"
, "bin": "./path/to/program" }

is same as

{ "name": "my-program"
, "version": "1.2.5"
, "bin" : { "my-program" : "./path/to/program" } }

We're getting the following output on a valid package.json with a man field for installing our manpage:

{ valid: false,
  errors: [ 'Type for field man, was expected to be object, not string' ] }

The package.json spec says that man can be either a single file path or an array of file paths.

The version field probably ought to be validated using the semver module, and the license field probably ought to be validated using the spdx module. Both of these are used by normalize-package-data which in turn is used by npm itself when parsing the package.json.

Other parsing/validation rules (for the npm spec, at least) ought to be brought in line with the normalization rules from normalize-package-data

If any dependencies have a version range with a caret (^) package.json-validator incorrectly identifies it as an invalid version range:

package.json is NOT valid
{ valid: false,
  errors:
   [ 'licenses field should have url',
     'Invalid version range for dependency package-json-validator: ^0.5.5'] }

See https://www.npmjs.org/doc/misc/semver.html for caret range validation.

A nice addition would be to use this as an npm script:

// package.json
{
  "scripts": {
    "test": "package-json-validator"
  }
}

Whoa! package-json-validator-ception!

Ran the repo's latest package.json through the online validator and testing the globally installed "pjv" module and saw the following warnings:

{
"valid": true,
"warnings": [
"Missing recommended field: keywords",
"Missing recommended field: homepage",
"Missing recommended field: bugs",
"Missing recommended field: licenses"
],
"recommendations": [
"Missing optional field: contributors",
"Missing optional field: files",
"Missing optional field: man",
"Missing optional field: directories",
"Missing optional field: config",
"Missing optional field: bundledDependencies",
"Missing optional field: optionalDependencies",
"Missing optional field: engines",
"Missing optional field: engineStrict",
"Missing optional field: os",
"Missing optional field: cpu",
"Missing optional field: preferGlobal",
"Missing optional field: private",
"Missing optional field: publishConfig"
]
}

I get errors when I try validating the following package.json file:

http://package.json.nodejitsu.com/

{
  "valid": false,
  "errors": [
    "Invalid dependency package name: 0",
    "Invalid version range for dependency 0: union",
    "Invalid dependency package name: 1",
    "Invalid version range for dependency 1: ecstatic"
  ],
  "warnings": [
    "Missing recommended field: homepage",
    "Missing recommended field: bugs",
    "Missing recommended field: licenses"
  ],
  "recommendations": [
    "Missing optional field: files",
    "Missing optional field: man",
    "Missing optional field: directories",
    "Missing optional field: config",
    "Missing optional field: optionalDependencies",
    "Missing optional field: engineStrict",
    "Missing optional field: os",
    "Missing optional field: cpu",
    "Missing optional field: private",
    "Missing optional field: publishConfig"
  ]
}

It looks like if I remove the specified bundledDependencies then I no longer get errors:

{
  "valid": true,
  "warnings": [
    "Missing recommended field: homepage",
    "Missing recommended field: bugs",
    "Missing recommended field: licenses"
  ],
  "recommendations": [
    "Missing optional field: files",
    "Missing optional field: man",
    "Missing optional field: directories",
    "Missing optional field: config",
    "Missing optional field: optionalDependencies",
    "Missing optional field: engineStrict",
    "Missing optional field: os",
    "Missing optional field: cpu",
    "Missing optional field: private",
    "Missing optional field: publishConfig"
  ]
}

npm install will warn the end-user if there's no repository field for a package, so it makes sense to warn the developer too :-)

For example,

npm WARN package.json [email protected] No repository field.
npm WARN package.json [email protected] 'repositories' (plural) Not supported.
npm WARN package.json Please pick one as the 'repository' field

As a bonus, it would of course be nice to warn about the inclusion of the unsupported repositories field at the same time.

The following package.json file is marked as invalid:

{
  "name": "tmp",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "dSebastien <[email protected]> (https://www.dsebastien.net)",
  "license": "ISC",
  "dependencies": {
    "@reactivex/rxjs": "5.0.0-alpha.7"
  }
}

output of pjv package.json:

{ valid: false,
  errors: [ 'Invalid dependency package name: @reactivex/rxjs' ] }

Re: https://www.npmjs.com/package/nsp

It may be nice to be able to opt-in to security checking using the nsp API, where you post the package.json to nsp and could display any potentially vulnerable modules.

Hi there, I'm using this module as part of a bigger validator for Ghost themes.

After I've checked that the package.json is valid, I want to use some of the fields to inform my report (name, version, description, etc) and eventually I'd like to add a few extra validations of my own which are Ghost-specific.

At the moment, I end up having to do some work twice. I can't parse the JSON and pass pre-parsed JSON to package.json-validator as it expects a string, but I also don't believe it's currently possible to get the parsed JSON back from PJV to do further work on.

I'm happy to submit a PR, but thought I'd check first, would the option to get the valid JSON back be something that would be accepted? Any thoughts or recommendations on naming or approach?

Example input:

{
  "name": "test",
  "version": "1.0.0",
  "author": "test",
  "devDependencies": {
    "test": "file:./"
  }
}

Expected result:

{
  "valid": true
}

Actual result:

{
  "valid": false,
  "errors": [
    "Invalid version range for dependency test: file:./"
  ]
}

Per https://nodejs.org/api/esm.html#esm_main_entry_point_export

To set the main entry point for a package, it is advisable to define both "exports" and "main" in the package’s package.json file:

{
"main": "./main.js",
"exports": "./main.js"
}

The benefit of doing this is that when using the "exports" field all subpaths of the package will no longer be available to importers under require('pkg/subpath.js'), and instead they will get a new error, ERR_PACKAGE_PATH_NOT_EXPORTED.

This encapsulation of exports provides more reliable guarantees about package interfaces for tools and when handling semver upgrades for a package. It is not a strong encapsulation since a direct require of any absolute subpath of the package such as require('/path/to/node_modules/pkg/subpath.js') will still load subpath.js.

Also the order within exports (and the order within exports subpaths, e.g., {exports: {"./feature": {browser: "./feature-browser.js", default: "./feature.js"}} and within nested conditions, e.g., {"exports": {"import": {"node": "./feature-node.mjs"}}}) could be enforced per https://nodejs.org/api/esm.html#esm_conditional_exports :

"node" - matched for any Node.js environment. Can be a CommonJS or ES module file. This condition should always come after "import" or "require".
"default" - the generic fallback that will always match. Can be a CommonJS or ES module file. This condition should always come last.

I was validating a package.json file and noticed it was complaining about the "q" module. I believe the current dependency name RegExp is trying to match 2 or more characters. We may need to switch a "+" to a "*".

PJV.js:7 packageFormat: /^[a-z0-9][a-z0-9\.\-_]+$/,

{
  "name": "foo",
  "version": "0.1.0",
  "dependencies": {
    "q": "0.9.7"
  }
}

It looks like the author field is required by package.json-validator, but not by npm.

I don't see any mention of the author field being required in the published npm package.json documentation. I only see that the name and version fields are required:

The most important things in your package.json are the name and version fields. Those are actually required, and your package won't install without them.

I tested this out against older and more recent versions of npm. I put together a very minimal module that contains ony name and version attributes, and attempted to declare that minimal module as a dependency of another empty module. Everything (install, uninstall, update, etc.) seems to work fine even though the minimal module doesn't contain the author attribute.

Am I missing something, or is this a bug?

Per the npmjs site, both license string and licenses object format are supported: https://npmjs.org/doc/json.html#license

{ "license" : "BSD" }

and

"licenses" : [
  { "type" : "MyLicense"
  , "url" : "http://github.com/owner/project/path/to/license"
  }
]

Hi, just wanted to flag up that the package.json in the repo states the version as 0.6.0, but on npm it says 0.6.1 😁

There are no tags since 0.5.6 and no changelog so I'm wondering what is in 0.6.1 🤔

Also: Is this module likely to be actively maintained again? I'm using it for a project and need to get some updates in. I can PR but my last issue didn't get a reply so I thought I'd ask before PRing or forking.

When checking dependencies or devDependencies I see errors on invalid semvers, but the same check doesn't seem to occur on peerDependencies.

I think this should be valid, but it is complaining:

{
  "name": "foo",
  "author": "peter",
  "version": "0.0.1"
}

The error I'm getting from the online validator is:

{
  "valid": false,
  "errors": [
    "String not valid for author, expected format is Barney Rubble <[email protected]> (http://barnyrubble.tumblr.com/)"
  ],
  "warnings": [
   ...
  ],
  "recommendations": [
    ...
  ]
}

Local dependencies paths are valid now but not considered as valid by app.
Here's local paths docs link

The following package.json gives me an error:

{
  "name": "bar",
  "version": "0.0.2",
  "dependencies": {
    "JSONSelect": "0.4.0"
  }
}

And the warning of "Invalid dependency package name: JSONSelect":

  "errors": [
    "Invalid dependency package name: JSONSelect"
  ]

Steps to reproduce:

1. On http://package-json-validator.com/ enter the URL: https://github.com/isaacs/node-tap

Actual results:

{
  "valid": false,
  "errors": [
    "Type for field license, was expected to be string, not object",
    "Type for field repository, was expected to be object, not string"
  ],
  "warnings": [
    "Missing recommended field: bugs"
  ],
  "recommendations": [
    "Missing optional field: homepage"
  ]
}

Expected results:

We should support the singular version of license. I figure @isaacs knows a thing or two about package.json and license is valid. I found https://www.npmjs.org/doc/files/package.json.html#license but it only mentions the shorthand version of the license as a strong, not as an object. And makes no mention of licenses[] plural.

I think it may be my mistake, but if it is I hope someone knows how to help me I'm using the npm package package-json-validator in a nodejs script and when I run the code it gives an error saying PJV.validate is not a function

My script:

var PJV = require("package-json-validator").PJV;

const data = "{
"name": "test",
"version": "1.0.0",
"description": "",
"main": "index.js",
"dependencies": {
"package-json-validator": "^0.6.3"
},
"devDependencies": {},
"scripts": {
"test": "echo "Error: no test specified" && exit 1"
},
"author": "",
"license": "ISC"
}";

PJV.validate(data, "npm", {
warnings: true, // show warnings
recommendations: true // show recommendations
})

This is my one gripe with npm. Seems an obvious addition to this package.

Per https://nodejs.org/api/esm.html#esm_package_json_type_field

Package authors should include the "type" field, even in packages where all sources are CommonJS. Being explicit about the type of the package will future-proof the package in case the default type of Node.js ever changes, and it will also make things easier for build tools and loaders to determine how the files in the package should be interpreted.

It could also be checked for the valid values "commonjs" or "module".

Thanks!

Clicking the homepage link presents the following malware alert from uBlock Origin:

uBlock Origin has prevented the following page from loading:

http://click.expmediadirect1.com/click?i=pW1KX8XbnF0_0

Because of the following filter:

||expmediadirect1.com^

Found in: uBlock filters – Badware risks 

This should not validate:

{
  "name": "hi",
  "version": "0.0.0",
  "scripts": {
    "hello:world": {}
  }
}

I've seen a ton of modules that specify fs and path in their dependencies.
http://npm.im/fs

It may be a bit hacky, but you could possibly store an array of built-in Node modules from https://nodejs.org/dist/latest-v6.x/docs/api/ (ie: "assert", "buffer", "child_process", "fs", "http", "path", etc) and then display warnings if the package.json uses any of those built-in modules.

Of course, there may be a valid reason to use the npm version of "path", so I guess they shouldn't be fatal errors, but I find most people may do npm i fs path -S by mistake and often don't want them or understand they have been built-in since Node 0.1. 🤷

It'd be super awesome if this could be abstracted and run as a Node.js module so I could integrate it w/ something like Grunt where my build would fail if the package.json file wasnt valid.

Submitting an issue so I can subscribe to notifications.

Hello!

Thank you for this great library!

However, right now, the validate function accepts the manifest in a string format, however, it would be great if it would accept a pre-parsed JSON object.

This would be beneficial in pipeline scenarios.

Thanks!

Error: "Type for field repository, was expected to be string,object, not string".

There even seems to be an error in the error message.

FYI I started looking into this because my plugin was out of date on npm. If you do npm info intl-tel-input (or if you check the website), it says the latest version is 2.0.10, when it is actually 3.4.0. I wondered if it might be a problem with my package.json, so I ran it on your site and got this same error, but couldn't figure out what was wrong with the repository field, so tried the samples and they failed too, as does the example on the npm page about package.json.

I'm getting an error with the following value in my package.json file:

"repository": "mozilla/fxa-profile-server",

package.json is NOT valid
{ valid: false,
  errors: [ 'Type for field repository, was expected to be object, not string' ],
  warnings:
   [ 'Missing recommended field: keywords',
     'Missing recommended field: contributors' ] }

I believe this was added in npm 1.3.10 (per http://dailyjs.com/2013/09/06/npm-updates/). In fact, I think this may be the npm issue: npm/npm#3783

Many projects don’t have any contributors other than the package author, so maybe either this should be a recommendation, or possibly even some kind of git check of [if] the number of contributors [> 1]… something like:

(($(git shortlog -s | wc -l) > 1))

I'm getting errors when trying to parse the following package.json file:

{
  "name": "foo",
  "version": "0.3.10",
  "author": "bar <[email protected]>",
  "description": "",
  "license": "MIT"
}

And the error is:

{
  "valid": false,
  "errors": [
    "Value for field version, 0.3.10 does not match format: /^[0-9]+\\.[0-9]+\\.[0-9+a-zA-Z\\.]$/"
  ],
  "warnings": [
    ...
  ],
  "recommendations": [
    ...
  ]
}

I checked http://semver.org/spec/v2.0.0.html and didn't see any mention of the patch version being limited to 0-9.

Yay Travis!

I think all you'd need is to create a .travis.yml file and add the following contents (as well as sign up at https://travis-ci.org/ and tell it to watch this repo):

language: node_js
node_js:
  - "0.10"

This should run npm install and npm test for you automatically. Then just add a fancy badge to your README.md to see the current status. We may need to tweak another couple things like adding before_install which installs the grunt-cli or whatever.

I'm getting errors when my dependency version range is set to "latest", which should be legit according to npm's package.json dependencies docs:

$ pjv --warnings
package.json is NOT valid

{ valid: false,
  errors:
   [ 'Invalid version range for dependency chai: latest',
     'Invalid version range for dependency jsxhint: latest',
     'Invalid version range for dependency mocha: latest',
     'Invalid version range for dependency sinon: latest' ],
  warnings: [ 'Missing recommended field: contributors' ] }

Where our devDependencies look a little something like this:

  "devDependencies": {
    "6to5ify": "^4.0.*",
    "chai": "latest",
    "gulp-sourcemaps": "^1.3.0",
    "jsxhint": "latest",
    "karma": "^0.12.*",
    "karma-6to5-preprocessor": "^3.0.*",
    "karma-browserify": "^3.0.*",
    "karma-chai": "^0.1.*",
    "karma-chai-plugins": "^0.2.4",
    "karma-chrome-launcher": "^0.1.7",
    "karma-firefox-launcher": "^0.1.*",
    "karma-mocha": "^0.1.*",
    "karma-react-preprocessor": "0.0.*",
    "mocha": "latest",
    "react-tools": "0.12.2",
    "sinon": "latest"
  }

Would be awesome to be able to paste a github url into the Enter a github repo link and then get a share type link which changes the URL of the page.

Can send to someone with a copy/paste and share the invalid package.json result with others...

Validating mysql package.json through http://package-json-validator.com returns invalid for repository shortcut syntax and npm auto-populated fields.

Results:

{
"valid": false,
"errors": [
"Url not valid for repository: mysqljs/mysql"
],
"warnings": [
"Missing recommended field: keywords",
"Missing recommended field: bugs"
],
"recommendations": [
"Missing optional field: homepage"
]
}

Reference pull request #1630

If I try to parse a Github package.json via the url method, I get the following error message

After debugging the error, I found out that it's caused by making "too many requests" to the Github API.

/**/angular.callbacks._1t({
  "meta": {
    "Content-Type": "application/javascript; charset=utf-8",
    "X-RateLimit-Limit": "60",
    "X-RateLimit-Remaining": "0",
    "X-RateLimit-Reset": "1484939293",
    "X-GitHub-Media-Type": "github.v3; format=json",
    "status": 403
  },
  "data": {
    "message": "API rate limit exceeded for xxx.xxx.xxx.xxx. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)",
    "documentation_url": "https://developer.github.com/v3/#rate-limiting"
  }
})

Would be nice if the error was more meaningful. Something like this would be nice

{
  "valid": "false",
  "critical":" Github API limit exceeded! Please wait a few minutes before making another request."
}

The following should be valid for contributors

{
  "contributors": [
    "Some Dude <[email protected]> (http://lebowski.com)"
  ]
}

but I'm getting the following:

  "errors": [
    "contributors field should have name",
    "contributors field should have email or url"
  ],

var PJV=require('package-json-validator').PJV;
PJV.validate(repoName, spec, options);

psjv -r repoName

This is try to fetch the required package.json from the npmjs.org based on the repoName and validate it, will be very useful for scripts that are programatically validated list of repos.

It doesn't warn about duplicated dependencies.

NPM latest version is 6 years old, can we get published a new one with latest code?

I use the syntax of the title so that I can have two different major version of one project as a dependency (one @1.x.x and one 2.x.x), but this validator doesn't recognize this syntax and outputs an error instead. It would be cool if this syntax was supported, but given that it is quite uncommon (to the best of my knowledge) I don't think this should be a priority.

The following package.json content can be used to reproduce this error.

{
  "name": "project",
  "version": "1.0.0",
  "private": true,
  "description": "...",
  "homepage": "https://github.com/ericcornelissen/project",
  "license": "MIT",
  "main": "lib/index.js",
  "repository": {
    "type": "git",
    "url": "https://github.com/ericcornelissen/project"
  },
  "dependencies": {
    "svgo-v1": "npm:[email protected]",
    "svgo-v2": "npm:[email protected]"
  }
}

I'm currently trying to get my package.json valided before submiting a new package. However, the validation is faling since I'm trying to use GitHub URLs in my dependencies.

From the npm docs:

As of version 1.1.65, you can refer to GitHub urls as just "foo": "user/foo-project".

However, if I use the following de

"dependencies": {
  "foo": "user/foo-project"
}

package.json-validator tell me that my package.json is not valid:

package.json is NOT valid
{ valid: false,
  errors: [ 'Invalid version range for dependency foo: user/foo-project' ] }

There are a few new license changes in newer versions of npm.

https://docs.npmjs.com/files/package.json#license
http://npm1k.org/

For valid license strings, see https://www.npmjs.com/package/spdx

I'm getting errors when trying to validate a version with a hyphen and label:

{
  "name": "foo",
  "version": "1.0.0-alpha",
  "author": "bar <[email protected]>",
  "description": "",
  "license": "MIT"
}

And the error is:

{
  "valid": false,
  "errors": [
    "Value for field version, 1.0.0-alpha does not match format: /^[0-9]+\\.[0-9]+\\.[0-9+a-zA-Z\\.]$/"
  ],
  "warnings": ["..."],
  "recommendations": ["..."]
}

Other examples (see sections 9-11 of http://semver.org/spec/v2.0.0.html) are:

Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.

Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.

Example: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.

Should be valid according to https://docs.npmjs.com/files/package.json#dependencies as of npm version 1.1.65

Example snippet to reproduce the erroneous "Invalid version range for dependency..." error:

  "dependencies": {
    "redis-scheduler": "nsue/redis-scheduler#patch-1"
  }

input: (simplified)

{
    "engines": [
        "node"
    ]
}

Results: (simplified)

{
  "valid": false,
  "errors": [
    "Type for field engines, was expected to be object, not object"
  ]
}