Repository navigation
Installing phantomjs-prebuilt fails due to no npm_config_tmp #1538
Description
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
Activity
chore(travis): dismiss yarn for now
chore(travis): setup travis CI (#58)
pgporada commentedon Feb 16, 2017
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}
weedgrease commentedon Mar 16, 2017
I'm experiencing this as well and running
yarn config set npm_config_tmp $HOME/.npm_tmpdidn't help. :(csvan commentedon Mar 26, 2017
@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 commentedon May 4, 2017
This looks like a duplicate of #1016 -- both seem to be about phantomjs-prebuilt failing due to
npm_config_tmpnot set 🤔pgporada commentedon May 4, 2017
It's like 3 lines of code to check and default the var in both projects. If
yarnis going for maximumnpmcompatibility, doing a check inyarnwould allow ayarnuser to not have theiryarn installblow up unexpectedly in their face. PhantomJS should handle it too because validating that you have vars is proper programming.dcecile commentedon May 4, 2017
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-prebuiltearlier than v2.1.8?pgporada commentedon May 4, 2017
@dcecile Most likely. Auditing all of that is a pain in the ass if you're not a JS developer.
Spongman commentedon Jul 13, 2017
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 commentedon Jul 13, 2017
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 commentedon Jul 13, 2017
I'm not in a position to drop it. It's a dependency of a dependency of a ....
csvan commentedon Jul 14, 2017
@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 commentedon Jul 15, 2017
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 commentedon Aug 26, 2017
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 commentedon Aug 26, 2017
Hi @adamreisnz!
This might be something that can be resolved with selective resolution feature
So entering something like below in your own package.json
adamreisnz commentedon Aug 26, 2017
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 commentedon Oct 12, 2017
yeah, this is still an issue. yarn is NOT a drop-in replacement for npm, as advertised.
kaylie-alexa commentedon Jan 8, 2018
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 commentedon Jan 8, 2018
seriously? how are any of those workarounds? there's nothing i can check into my project that will fix this bug.
kaylie-alexa commentedon Jan 8, 2018
@Spongman did you try using the resolutions field?
The feature is meant to override the defined versions in nested dependencies' package.json
https://yarnpkg.com/en/docs/selective-version-resolutions
Spongman commentedon Jan 8, 2018
yes. it breaks those packages.
kaylie-alexa commentedon Jan 8, 2018
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 commentedon Jan 8, 2018
@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 commentedon Jan 8, 2018
i would love to. but again, that's out of my control.