inspect-package.js

//
// Option 1
// This is how it's actually done.
//

var config = {} // the equivalent of command-line switches
  , path = require("path")

require("npm").load(config, function (er, npm) {
  if (er) return doWhateverItIsYouDoWithErrors(er)

  // thingThatCanBeInstalled can be like:
  // "name"
  // "name", "version"
  // "http://x.y/package.tgz"
  // "/path/to/folder"
  // "/path/to/package.tgz"
  npm.commands.cache.add(thingThatCanBeInstalled, function (er, data) {
    if (er) return doWhateverItIsYouDoWithErrors(er)

    // Now it's sitting in the cache, just as it will be when its installed.
    // the data object is what npm sees from the package.json file.
    // this is how npm does publishes, installs, etc.  Anything that interacts
    // with package contents goes through the cache.  It's a single gateway
    // for cleanup, validation, etc.
    var theCodeIsIn = path.resolve(npm.cache, data.name, data.version, "package")
      , theTarballIs = path.resolve(npm.cache, data.name, data.version, "package.tgz")
      , theDataIs = path.resolve(npm.cache, data.name, data.version, "package.json")

    // Use it for good!
  })

})

//
// Option 2
//
// You could just do this, if you don't want to go through so much trouble.
// I often do this to quickly see what's inside a tarball on the registry.
//
// $ npm view express dist.tarball | xargs curl | tar ztv

Note: the code in the cache is not what you get when you use require() or actually run the package. That stuff is unpacked, built, injected with dependencies, and symlinked into various places, and typically lives in a node_modules folder somewhere.

Right. That's exactly the issue I was bumping into and my work-arounds were brittle.