Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Instructions in testing guide fail to run client tests from the command line #8225
While following the instructions in the testing guide for configuring command line execution using PhantomJS (https://guide.meteor.com/testing.html) I consistently see the error message
Steps to reproduce on a Linux machine:
This can be worked around by running the following, which leads me to believe this is an issue with meteor not correctly doing the rebuild, and that this is not an issue with the phantomjs-tests package.
Related discussion on DispatchMe/meteor-mocha-phantomjs#35
referenced this issue
Jan 7, 2017
@benjamn I have been getting a lot of complaints about this. All I did was publish dispatch:phantomjs-tests with a couple small changes from Mac, but it was done on latest Meteor for the first time so this effectively caused a breaking change in a non-breaking version. It seems that
I thought maybe I could fix by doing publish-for-arch anyway, but it would not let me.
After some digging I have found what I think to be the issue. Pardon my unfamiliarity with meteor internals.
In commit 861880b the behavior of meteorNpm.rebuildIfNonPortable was changed by @benjamn from looking at a packages' npm modules and rebuilding all of them if any was non-portable, to a more "aggressive" approach of only rebuilding individual non-portable npm modules.
The old behavior worked because dispatch:phantomjs-tests has the module meteor-force-non-portable which would force a rebuild of all modules under
I confirmed that changing the code to see phantomjs-prebuilt as non-portable caused the correct rebuild to happen and fix the reported issue.
I think this could be fixed by additionally look in each package to see if the scripts section of package.json contains a install or preinstall script. The npm docs say "[t]he only valid use of install or preinstall scripts is for compilation which must be done on the target architecture." This will add some file read and parsing time in additional to causing a few more rebuilds to happen but it should give correct behavior. Additionally I suspect instead of heuristically looking for .node files a check could directly be made for a .gyp config file, but that may not be true in all cases and would at least break the meteor-force-non-portable package.
Note: I noticed while debugging the dispatch:phantomjs-tests package was actually packaged with cached portable status files like
@danstiner That analysis checks out with me (and I wrote the logic that you're analyzing)!
I think this is a totally reasonable approach. I would be cautiously open to going back to the old behavior of rebuilding everything, but this middle ground strikes me as a safe compromise. If it's safe to rebuild everything, then it's safe to rebuild a few additional packages.
Would you have time to submit a pull request for that change? Specifically, make
added a commit
Feb 9, 2017
@benjamn I can confirm that the
@abernix If MDG is updating the testing guide: could you focus more on dispatch:mocha-phantomjs, rather than on the other dispatch options ? Despite this error it seems like dispatch:mocha-phantomjs seems to be currently the most maintained package of them all.
This was referenced
Feb 10, 2017
By the way, @aldeed, although this issue was in the back of my head, I independently encountered the same problem while trying to add the
I'm really happy to get this fixed, because running the
As far as I remember, the one thing some people like about the
@benjamn Nice! and you're welcome.
@aldeed I think it would be great to consolidate a bit. I'm for any solution that allows me to run client and server tests locally and in CI. Phantomjs seems to be the way to do this. Couldn't you consolidate in a way that checks is phantomjs is installed, and if not fall back on other methods?
@keyscores I don't see any benefit to consolidating further. You can add multiple driver packages and multiple npm scripts for them, and then run any script you want on CI and any script you want locally. And if you never want to run client tests in your browser, then you only need the phantomjs one anyway. Complicating the packages will just make them harder for others to understand and contribute to.