Use npm's own module to obtain the paths

[eush77]

This PR fixes #2 by switching to completely different method of solving the problem. Instead of packing a tarball and then inspecting it, this version uses the module responsible to do the same job in npm itself.

As a bonus, it also takes significantly less time compared to the master version due to reduced disk IO utilization.

Path processing logic was constructed to revert these lines.

[eush77]

As @ljharb pointed out, prepublish script should be run anyway (if there is one). I will update this PR shortly.

[eush77]

ping @thlorenz

[thlorenz]

Interesting, I think @timoxley has a module that already does it this way.

prepublish script should be run anyway (if there is one)

Not sure about that. This is intended as a dry-run. If I just want to check something I don't expect any scripts that change the state of my module to run as well.

Also please separate into two PRs, each adding/changing one feature. First two commits should be one, last two another one.

You can just remove last two commits from this one and create another PR for those last two.

[timoxley]

yep: https://github.com/timoxley/pkgfiles

Note though that mine takes it a step further, rather than just requiring whatever version of fstream-npm happens to be bundled into irish-pub, pkgfiles extracts the exact fstream-npm that the npm-cli uses via some sneaky business in pkgresolve.

var resolve = require('pkgresolve')
// …
function pkgFiles(dir, fn) {
  resolve('fstream-npm').fromGlobal('npm', function(err, fstreamPath) {
    // …
  })
})

This necessary because there's a good chance that if the fstream-npm versions differ, the files they include will differ thus making the whole endeavour pointless.

[thlorenz]

Ok, so seems to me that having two modules using different algos is more useful than just duplicating. This way users can choose which they prefer. So let's not use fs-stream in here but instead point at pkgfiles in the readme as an alternative.

Gonna close this for now mainly cause it's doing too much in one PR and I don't want to merge first half of it.

If you feel strongly about running prepublish please provide this via another PR @eush77. I'm open to this as long as it isn't the default but gets turned on via a flag instead.

[ljharb]

@thlorenz I agree that the module shouldn't change states as a result of running irish-pub - but, you can't possibly know what will actually be published unless you include build artifacts that a prepublish script might generate. For example, the es7-shim browserifies itself and adds a dist/es7-shim.js file on prepublish, specifically so it will be included only in the npm tarball.

[thlorenz]

@ljharb agreed, which is why I'm open to allow this feature via a flag.

[eush77]

@thlorenz

Also please separate into two PRs, each adding/changing one feature. First two commits should be one, last two another one.

Last two commits on this branch do not introduce any new features compared to the master. npm pack itself runs npm prepublish script (see also #2), and so I was trying to emulate this behavior for consistency here.

This is intended as a dry-run. If I just want to check something I don't expect any scripts that change the state of my module to run as well.

Then this module needs some work. I'm not sure how would you do that without digging into how npm works internally and probably coming down to using fstream-npm anyway ;)