starting test with Jest 25 errors out with: "TypeError: Cannot read property 'runCLI' of undefined"

[lukka]

Tests properly running with gulp-jest and jest version 24, when upgrading jest to 25+ trigger the error in the subject.
is this project abandoned? Last published package was on 2018.
I am using as a workaround the following package instead: https://www.npmjs.com/package/gulp-jest-acierto

[jacobq]

I was wondering the same thing. Relevant SO post is here: https://stackoverflow.com/questions/61212282/cannot-read-property-runcli-of-undefined-in-gulp-jest
See also jestjs/jest#9512

[jacobq]

I published a scoped version in case anyone wants to try while #65 is still awaiting acceptance.
"gulp-jest": "https://registry.npmjs.org/@jacobq/gulp-jest/-/gulp-jest-4.0.3-PR65.tgz",

[paceaux]

I appreciate that there's workarounds for while we wait for this PR (thanks @jacobq ) ... But I'd like to point out that @jacobq/gulp-jest and julp-jest-acierto both incorrectly identify themselves. They have identical readmes and near-identical NPM package.json files. They should be updated to correctly identify the repository and author, otherwise it's REALLY confusing and misleading on NPM

[jacobq]

They should be updated to correctly identify the repository and author, otherwise it's REALLY confusing and misleading on NPM

Thanks for sharing this perspective. I guess I'm so accustomed to forks on GitHub that the thought didn't cross my mind. Could you help me better understand what you would like to see changed?

Since my changes are very small and I do not intend to maintain a separate branch for an extended period of time I don't think that it would make sense to do something like, for example, find/replace author's name/URL/etc. in the README.md and package.json files. My repo on GitHub says right at the top "forked from aarontrank/gulp-jest" and the package on npm uses the standard @scope/ format.

I suppose I could change the default branch to show a README.md that explicitly states that this is just a fork and include links to related issues. That seems like extra work that I wouldn't have expected to add much value, but if you're saying that you believe this would help clear up confusion I don't mind.

[paceaux]

@jacobq I'd like to see the things that are inaccurate, but visible to a user of NPM, changed:

• repository url in package.json
• website url in package.json
• name in package.json
• installation instructions in readme

When I came across this bug, I started searching around for what to do. I noticed on NPM two more packages. I also noticed that they were presented identically ; from NPM I had no idea that two packages were fixing a bug in the main package. It looks like two people cloned the main one with no explanation. I had to come over to Github and search on Github to discover the bug and two independent solutions.

If you could update your package.json's and your READMEs, you're communicating to the 10,000+ weekly downloaders of gulp-jest that you're not malware or a CS grad learning NPM, but someone who has a solution to a specific bug.

[jacobq]

I had to come over to Github and search on Github to discover the bug and two independent solutions.

You make it sound like that is a bad thing. I would argue that searching the existing GitHub issues should be one of first troubleshooting steps.

@jacobq I'd like to see the things that are inaccurate, but visible to a user of NPM, changed:

• repository url in package.json
• website url in package.json
• name in package.json
• installation instructions in readme

It seems that we disagree on what is "inaccurate" in this case. As I tried to explain before, I am not making a separate project, just a PR. It's much more like another release/version than an alternative module. I want people to be directed toward the canonical repository rather than my fork. If I had commit access here then I'd have created the branch on this same repository rather than a separate one.

When I came across this bug, I started searching around for what to do.

I am sorry that your experience was frustrating. Admittedly, figuring out what to search for can sometimes take nearly as much time as actually correcting the problem. Do you recall what your search queries were? I just tried a quick web search for jest TypeError: Cannot read property 'runCLI' of undefined" and the first hit was stryker-mutator/stryker-js#1983 which describes the cause of the problem and includes references to this issue.

I noticed on NPM two more packages. I also noticed that they were presented identically ; from NPM I had no idea that two packages were fixing a bug in the main package. It looks like two people cloned the main one with no explanation. I had to come over to Github and search on Github to discover the bug and two independent solutions.

If I am not mistaken, this is standard practice for forks. I recommend checking the "Versions" section whenever you encounter a scenario like this. I had thought that tagging the release with "PR65" would be a sufficiently helpful clue but perhaps it was not.

If you could update your package.json's and your READMEs, you're communicating to the 10,000+ weekly downloaders of gulp-jest that you're not malware or a CS grad learning NPM, but someone who has a solution to a specific bug.

I will keep this in mind for the future. In this case, I did not mean for my fork to become the solution path for the masses but rather for developers willing to try it in non-critical / beta environments to speed-along the PR.

[paceaux]

@jacobq I probably should've lead with, "thank you," because you did have a solution to the problem that I had. Being nitpicky about how I feel you went about it should be secondary to the fact that without your solution, I'd be in a quandary. So again, thank you.

All things considered, yes, there were "clues" that I used to help me figure out what was going on; "tags" was just such a clue. I just don't like being a detective all the time.

I have brought this up with NPM, too because ultimately, it's on them, not you. You had a solution and it should've been easy to make it clear what you had, and it wasn't.

[stepheneb]

@jacobq thanks for temporarily publishing a package I can use until this pull request gets merged.

Running jest tests is working after replacing gulp-jest: ^4.0.3" with your package.

My current devDependencies:

"devDependencies": {
    "@babel/core": "^7.12.9",
    "@babel/preset-env": "^7.12.7",
    "@babel/preset-typescript": "^7.12.7",
    "babel-jest": "^26.6.3",
    "browser-sync": "^2.26.13",
    "esm": "^3.2.25",
    "gulp": "^4.0.2",
    "gulp-jest": "https://registry.npmjs.org/@jacobq/gulp-jest/-/gulp-jest-4.0.3-PR65.tgz",
    "gulp-sass": "^4.1.0",
    "jest": "^26.6.3",
    "jest-cli": "^26.6.3",
    "node-sass": "^5.0.0"
  }