Installing phantomjs-prebuilt fails due to no npm_config_tmp

[joshkel]

Do you want to request a feature or report a bug?

Bug (maybe - Yarn's behavior is not necessarily incorrect, but it's incompatible with NPM)

What is the current behavior?

yarn add phantomjs fails with the following error:

error /home/jkelley/t2/node_modules/phantomjs: Command failed.
Exit code: 1
Command: sh
Arguments: -c node install.js
Directory: /home/jkelley/test/node_modules/phantomjs
Output:
PhantomJS not found on PATH
Phantom installation failed [TypeError: Path must be a string. Received undefined] TypeError: Path must be a string. Received undefined
    at assertPath (path.js:8:11)
    at Object.posix.join (path.js:479:5)
    at findSuitableTempDirectory (/home/jkelley/t2/node_modules/phantomjs/install.js:127:30)
    at /home/jkelley/test/node_modules/phantomjs/install.js:476:19
    at nextTickCallback (/home/jkelley/t2/node_modules/kew/kew.js:47:28)
    at nextTickCallbackWith0Args (node.js:420:9)
    at process._tickCallback (node.js:349:13)

Investigation revealed that the problem is that phantomjs 2.1.7 unconditionally expected the npm_config_tmp environment variable to be passed down by NPM. Yarn doesn't do this, so Yarn fails to install phantomjs in cases where NPM succeeds.

This is probably a bug in the phantomjs package (the current phantomjs-prebuilt package fixes it), but phantomjs is a popular package and probably not the only package to make this mistake, so it would improve Yarn's compatibility with NPM to pass npm_config_tmp.

A simple workaround for phantomjs in particular is to set TMPDIR before calling yarn.

If the current behavior is a bug, please provide the steps to reproduce.

yarn add phantomjs

What is the expected behavior?

yarn add phantomjs works.

Please mention your node.js, yarn and operating system version.

Node 4.6.1, Yarn 0.16.1, Ubuntu 14.04

[pgporada]

Is there any traction on this from yarn upstream?

This is what I have to do to get yarn working for apps that use phantomjs{,-prebuilt}

TMPDIR=/tmp yarn install

[weedgrease]

I'm experiencing this as well and running yarn config set npm_config_tmp $HOME/.npm_tmp didn't help. :(

[csvan]

@pgporada is this really a problem for the Yarn team to fix? I think it would be better to try to get PhantomJS not to depend on this var. See e.g. Medium/phantomjs#673

[dcecile]

This looks like a duplicate of #1016 -- both seem to be about phantomjs-prebuilt failing due to npm_config_tmp not set 🤔

[pgporada]

It's like 3 lines of code to check and default the var in both projects. If yarn is going for maximum npm compatibility, doing a check in yarn would allow a yarn user to not have their yarn install blow up unexpectedly in their face. PhantomJS should handle it too because validating that you have vars is proper programming.

[dcecile]

The PhantomJS NPM was updated to fix the problem back in July 2016 (v2.1.8) via Medium/phantomjs@5e6598f.

It seems like for some reason people are still encountering this issue... maybe other NPM packages depending on a phantomjs-prebuilt earlier than v2.1.8?

[pgporada]

@dcecile Most likely. Auditing all of that is a pain in the ass if you're not a JS developer.

[Spongman]

seems like yarn isn't ready for prime-time :(

should it be trivial to automatically, and periodically determine which npm-installable packages are failing with yarn?

[csvan]

Yarn is certainly ready for prime-time. We use it in production environments and it works great.

For this particular case, instead consider dropping PhantomJS. From what I gather it is abandoned, and vastly inferior to e.g. Chrome Headless anyhow.

[Spongman]

I'm not in a position to drop it. It's a dependency of a dependency of a ....

[csvan]

@Spongman I feel you, I had the same situation with a current project just recently. Took some dependency hacking but it was certainly worth getting rid off.

[Spongman]

you misunderstand me. i don't have write access to that package.json. what you're suggesting is that, in order to work around a bug in yarnpkg, i need to find replacements for >90% of my dependencies.

that's like Linus saying 'yeah, sorry, we broken open(), find libraries that don't use it..."

[adamreisnz]

So... this is still an issue? I sadly can't set variables before running yarn on Heroku, so I guess back to npm installs it is.

[kaylie-alexa]

Hi @adamreisnz!
This might be something that can be resolved with selective resolution feature
So entering something like below in your own package.json

resolutions: {
  "**/phantomjs-prebuilt": "2.1.8"
}

[adamreisnz]

Thanks @kaylieEB , I've actually taken the advice most people recommended with regards to PhantomJS and switched to Chrome headless. Was a bit of a mission to set it up on Heroku, but I managed. So now everything is working happily again with yarn!

[Spongman]

yeah, this is still an issue. yarn is NOT a drop-in replacement for npm, as advertised.

[kaylie-alexa]

Closing due to inactivity and workarounds mentioned above (Using phantomjs-prebuilt 2.1.8, setting TMPDIR, or overriding any nested dependency using selective resolutions)

[Spongman]

seriously? how are any of those workarounds? there's nothing i can check into my project that will fix this bug.

[kaylie-alexa]

@Spongman did you try using the resolutions field?

you misunderstand me. i don't have write access to that package.json. what you're suggesting is that, in order to work around a bug in yarnpkg, i need to find replacements for >90% of my dependencies.

The feature is meant to override the defined versions in nested dependencies' package.json
https://yarnpkg.com/en/docs/selective-version-resolutions

[Spongman]

yes. it breaks those packages.

[kaylie-alexa]

Would you mind sharing your package.json and the error message you're seeing? I also think we can track this in #2472, since the problem is a compatibility issue with npm env variables rather than with the particular package

[adamreisnz]

@Spongman if at all possible, I would still strongly recommend switching from PhantomJS to Chrome headless. Works well, and PhantomJS is not going to be maintained anymore.

[Spongman]

i would love to. but again, that's out of my control.