abraham / pkg-ok

👌 Checks paths and scripts defined in package.json before you publish

pkg-ok

pkg-ok checks paths and scripts defined in package.json before you publish 👌

• Ensures paths defined in main, bin, module, types, typings, es2015, browser, and exports exist
• Ensures paths defined in main, bin, and browser are relative
• Ensures bin scripts use cross-platform line endings

Usage

npm install pkg-ok --save-dev

// package.json
{
  "main": "oops_this_file_doesnt_exist.js",
  "scripts": {
    "prepublishOnly": "... && pkg-ok"
  }
}

npm publish
# Error!
# Since main file doesn't exist, publish is blocked

CLI

Check the package.json in the current directory.

pkg-ok

Check the package.json in a specific directory.

pkg-ok some/directory

Check additional package.json fields or bin files.

pkg-ok --field someField --bin script.sh

API

const pkgDirectory = __dirname;

pkgOk(pkgDirectory, {
  fields: ['someAdditonalField'],
  bin: ['someAdditionalScript.sh'],
});

License

MIT

pkg-ok's Issues

Suggestion: verify no dependencies are locally linked

A problem I often have is I'm working on two packages, e.g. my-library and my-cli, and the latter depends on the former. (Doesn't have to be a CLI, this is just for illustration.) In this situation, it's common to do npm link my-library from my-cli during development. But then you might forget that this dependency is linked locally, and you think my-cli is all ready to publish (automated and manual testing seems to show it's all working nicely), so you publish it... But then it turns out the published version doesn't work, because you forgot to unlink, bump and republish the library, and then update the dependency for real in my-cli.

So it might be useful to add a check that prevents you publishing the package if any of its direct dependencies are local symlinks.

Pass other package.json's as arguments

Basically:

# runs on ./package.json
pkg-ok
pkg-ok package.json

# runs on ./packages/name-of-package/package.json
pkg-ok packages/name-of-package
pkg-ok packages/name-of-package/package.json

# runs on multiple arguments
pkg-ok package.json packages/name-of-package/package.json

# runs on globs, respecting .gitignore
pkg-ok **/package.json

No longer maintained?

Hi typicode
We use pkg-ok regularly. Thanks for the tool.
But since two years it has not been maintained. Will you not update the tool anymore?

Browser field (and others?) may need refinement

Browser field (and others?) may need to refined:
https://twitter.com/AndaristRake/status/1048164567698886656

Thanks a lot to @Andarist for pointing that out! 👍

[Feature Request] Support for "module", "es2015", "typings" fields

Hey, it would be really awesome to not only check for the "main" file, but also for the files defined in the "module", "es2015" as well as "typings" fields. For example, this would be especially interesting for people (like me) developing Angular 2+ libraries - which (at least since Angular 4) also contain the fields named above.

Do you have time to extend the library? Or should I give it a try and open a PR?

Test CLI on multiple OSes

The CLI should be tested that it can be run on windows-latest, ubuntu-latest, and macos-latest.

'SyntaxError: Unexpected token {' when running with node 4 and node 5

Hi there, I recently updated a project and when running pkg-ok, it seems to fail on the following versions:

• pkg-ok 2.2.0

$ node --version
v4.9.1
$ npm --version
2.15.11
$ nvm --version
0.33.11
11.49s$ npm install 

How it's failing on my side:

husky
CI detected, skipping Git hooks installation
> [email protected] prepublish /Users/travis/build/GabLeRoux/cisco-password-decoder-cli
> pkg-ok
/Users/travis/build/GabLeRoux/cisco-password-decoder-cli/node_modules/pkg-ok/index.js:86
function pkgOk (dir, { fields = [], bin = [] } = {}) {
                     ^
SyntaxError: Unexpected token {
    at exports.runInThisContext (vm.js:53:16)
    at Module._compile (module.js:373:25)
    at Object.Module._extensions..js (module.js:416:10)
    at Module.load (module.js:343:32)
    at Function.Module._load (module.js:300:12)
    at Module.require (module.js:353:17)
    at require (internal/module.js:12:17)
    at Object.<anonymous> (/Users/travis/build/GabLeRoux/cisco-password-decoder-cli/node_modules/pkg-ok/bin.js:3:15)
    at Module._compile (module.js:409:26)
    at Object.Module._extensions..js (module.js:416:10)
npm ERR! Darwin 16.7.0
npm ERR! argv "/Users/travis/.nvm/versions/node/v4.9.1/bin/node" "/Users/travis/.nvm/versions/node/v4.9.1/bin/npm" "install"
npm ERR! node v4.9.1
npm ERR! npm  v2.15.11
npm ERR! code ELIFECYCLE
npm ERR! [email protected] prepublish: `pkg-ok`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the [email protected] prepublish script 'pkg-ok'.
npm ERR! This is most likely a problem with the cisco-password-decoder package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     pkg-ok
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs cisco-password-decoder
npm ERR! Or if that isn't available, you can get their info via:
npm ERR! 
npm ERR!     npm owner ls cisco-password-decoder
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR!     /Users/travis/build/GabLeRoux/cisco-password-decoder-cli/npm-debug.log

https://travis-ci.org/GabLeRoux/cisco-password-decoder-cli/jobs/378766686

Note: I'm ok with it as I personally don't really care about node 4 or node 5. I'm not even sure if it's exactly a problem with pkg-ok, but I see your travis build only seem to run against v10.0.0 and Node 6.

For now, I'll simply disable node 4 and node 5 on my side ;)
Thanks for this nice package 👍

Use PackageJson type

Replace type Pkg = any;

import { PackageJson } from 'type-fest';

Any plans for checking the files array or npmrc

I am regular user of pkg-ok and loves it 😄

I try to be explicit about the files I publish to the npm using the files array or the .npmrc file. I have been bitten quite a few times, where as per pkg-ok the paths are correct, however, I forgot to add them to the files array.

I am checking to see if you have any plans to check the published files and then validate paths. Not only it makes sure that the path exists, it also makes sure that paths are also published to npm.

I am happy to work on this feature (only if you want to add it).

Thanks

Suggestion: let the API accept a JSON object

If a package.json has already been parsed, it doesn't make sense to then have pkg-ok do it again:

// Override
function pkgOk(pkg: PackageJson, { fields = [], bin = [] }: Options = {})

Or maybe even from a string too:

function pkgOk(pkg: string, { fields = [], bin = [] }: Options = {})