node-tap v1.0.0 introduces a bunch of consistency and functionality upgrades in the test experience, along with a suite of pretty reporters ported from Mocha's default set. The semantic change that most dramatically affects npm's use (and will likely cause a bit of wailing and gnashing of teeth among other tap users) is that 't.test(...)' is now executed immediately, as long as there is not another test currently in progress. Indeed, everything that the Test class does, it does right away at the moment of calling the function, never using nextTick to defer anything. This means that, for example, a 'console.log' in the middle of a bunch of tests will print its output in the context of the associated test output, instead of having the console.log happen first, and then all of the TAP data deferred until later. For new node-tap users, this has been a significant stumbling block. However, it is a breaking change, and requires that test fixture objects have to be set up in advance of being used by a test, since it's no longer a guarantee that everything at the top (module) level will be executed before any test blocks. Also, the statSync in config-meta was changed to an lstatSync, since I have been developing with tap link-installed, and the directory crawling was sending my system into a tailspin otherwise. It seems like this would happen any time one of the npm deps was link-installed, so it's probably a good idea anyway.
This makes the '^' operator stricter for 0.x.y versions, even if 'x' is not 0. As a direct result, several *other* deps had to be updated, because they either depended on semver 2.x, or because the new stricter rules meant that they (or their deps) were no longer valid. The update to 'read-installed', in particular, causes a test failure. That update must be rolled back, or the test made to pass, prior to a stable npm 2.0.0 release going out.
Fixes #5591 The root cause here is that a change from 022 (a number in octal literal format) to '022' (a string) caused the string to later be interpreted as a decimal number, making for some wacky umask values. Solution is multipart. First, use the actual process.umask() value from the user's environment. This is almost certainly what they want anyway. Second, validate all default values just like we do with user- supplied values, rather than trusting them to never be wrong. This would've found the problem much sooner, while in dev. This second part requires that we allow a value of null for 'path' type args, allow 'undefined' for the 'local-address' config, and avoid looking up a cafile of 'null', all of which are good hygenic things to add defense-in-depth anyway.