Whoops, don't merge. I reviewed my validation. Hold your horses, I'll update.

This turned out to be more complex than I thought, due to various bugs and weird stuff in NPM. From the "Files and Ignores" section:

"The consequences are undefined" if you try to negate any of the files entries (that is, "!foo.js"). Please don't. Use .npmignore.

Then there is the fact that NPM doesn't respect .npmignore, which is bug npm/npm#11669 💩

There's a workaround, though:

Also: .npmignore/.gitignore in subdirectories DO override the top level files.

@fatso83 any ETA on the resolution for this ?
It fails production builds for us - as a dirty work around I need to explicitly add nise@1.2.0 in my package.json file. Which is bad cause I'm pulling this from sinon.

Explicitly adding nise@1.2.0 doesn't even seem to work in Yarn

@webdevian maybe you need to clean your lock file so it removes any reference of nise@1.2.1 ?
did the trick for me through npm uninstall nise && npm install nise@1.2.0 --save

This is now correct, as the output from tar doesn't contain any test references (rm -r package; npm pack 2>/dev/null && tar tzf nise-1.2.1.tgz 2>/dev/null) 2>/dev/null | grep test

Maybe the latest tag should be moved also to 1.2.0.

@fatso83 I see the deprecation message, but the issue is still there... can't you just unpublish this version until it is fixed ?
It will fail all builds using sinon, and other libraries that pull this package with a carret-ed version...

The fix in Yarn (v1) is to use a resolution

"resolutions": {
  "nise": "1.2.0"
},

Version 1.2.2 was released some minutes ago and version 1.2.1 has been retracted, as per @f-roland's suggestion:

npm i nise@1.2.1
npm ERR! code ETARGET
npm ERR! notarget No matching version found for nise@1.2.1
npm ERR! notarget In most cases you or one of your dependencies are requesting
npm ERR! notarget a package version that doesn't exist.

I was under the impression that NPM couldn't unpublish after the leftpad incident, and thought the deprecation thing would do more or less the same thing.

Well luckily, unpublish still works :)
I don’t know what your release cycle is, but you could avoid this by publishing pre-release versions first, as those would be skipped by most user until you can make sure it’s iron-clad.

This is especially important when you are required by big libraries like sinon that are very widely used !

@f-roland Not sure if that would be avoiding anything, as very few people actively seek out pre-releases of libraries.

I would rather have someone suggest a good postbuild step for our CI server that validated the built package. #helpwanted