kevva / bin-wrapper

Binary wrapper that makes your programs seamlessly available as local dependencies

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

run() fails if use() points to existing file

brettp opened this issue · comments

_find() just needs a try / catch block around the which statement. PR and test incoming.

I don't think this is necessary. Could you tell me when this happens? Your "fix" is just pretending that the error doesn't exists and returning true in each case.

And btw, keep the existing code style when sending PRs, makes everyone a little happier.

This is the root problem of imagemin/optipng-bin#44.

optipng ships with binaries, but they're not being used because they're in the wrong place (will send a PR for that later) and bin-wrapper could die even if they were.

How are they in the wrong place? This only happens on Windows so it's nothing wrong with this module but rather something Windows specific. I never had any problems installing on Windows though.

You can have a look at https://ci.appveyor.com/project/ShinnosukeWatanabe/imagemin-optipng too. optipng installs fine.

I suggest running the tests to see what's going on. The tests fail without this change if a binary already exists in the location specified by dest() and src().

Your "fix" is just pretending that the error doesn't exists and returning true in each case.

No, it's not. The check still occurs when it needs to. The line:

return file.path.indexOf(which.sync(bin)) === -1;

... checks if the binary exists and is in the same path as the file being inspected. It returns true if the paths are not the same. Which throws if the binary isn't found. If the binary isn't found, it's not going to have the same path as the file being inspected, so it needs to return true.

And btw, keep the existing code style when sending PRs, makes everyone a little happier.

What styles need adjusted? Happy to rebase if you can be more specific.

How are they in the wrong place?

Because the dest path isn't distinguished by platform when called. Look in the vendor directory and you'll see a optipng sitting at the root because it is always downloaded instead of using the bundled ones.

You're right. It does produce an error. I'm going to include the try catch.

... checks if the binary exists and is in the same path as the file being inspected. It returns true if the paths are not the same.

Well, not quite. It checks if the files path is in a npm installed directory using https://github.com/timoxley/npm-which.

Because the dest path isn't distinguished by platform when called. Look in the vendor directory and you'll see a optipng sitting at the root because it is always downloaded instead of using the bundled ones.

It's downloading the one for your system into the vendor root. The binaries aren't actually shipped with npm.

Thanks for finding this!

Thanks for finding this!

You're welcome!

It's downloading the one for your system into the vendor root. The binaries aren't actually shipped with npm.

Right, but they're shipped with opipng: https://github.com/imagemin/optipng-bin/tree/master/vendor

Yeah, they are downloaded from the github repo (see this). We don't want to include all binaries when installing from npm because it'll take more time.

👍

I was looking at the full clone.