Hi,
I'm trying to replace my tape test runner by Jest with the snapshot testing strategy. I'm currently supporting a developer environment based on gulp where I offer a bunch of utility tasks based on the needs of my organization, here is the project:
https://github.com/grommet/grommet-toolbox
One of my tasks is gulp test, I tried looking for gulp wrappers for jest and I found this project here:
https://github.com/Dakuan/gulp-jest
The problem is that it uses an old version of jest with the jest.runCLI function, I tried to update it to Jest 14.0 but I cannot find the runCLI anymore in the API.
Is there a reason it has been deprecated?
I understand the CLI itself offers a lot of the things I offer in my developer environment as: code coverage, watch mode, bail. But I still would like to leverage the Istanbul capabilities and the ability to pipe Jest with my other existing tasks like js linting. I know i could do it myself in the package.json, but my developer environment abstract most of the complexities of configuring libraries for UI development. And the configuration through package.json makes it harder to share common configuration for similar projects inside my organization.
What is the recommended way to run jest from a task runner like Gulp?
Never mind, runCLI is still a function inside the jest-cli project.
Documentation around it would be great though 馃槃
hey @alansouzati !
from my experience, things like grunt and gulp tend to add complexity to CLI tools rather than solve problems, however i understand that you're trying to abstract the configuration for end users, and if you're working on some shared set of build utils that is used by multiple projects it can become a pain.
i'd say the simplest solution would be to just invoke a child process from your gulp task and proxy the stdout/stderr to your main process. to abstract configuration you might want to pass a JSON config to the CLI
something like
jest --config '{"rootDir": "/a/b-c", ...}'
that json config you can generate dynamically in your gulp task based on what you're trying to do
i don't think it's documented yet, but we've been using this option in some of our projects.
We'll be working on simplifying our configuration pretty soon to, and most likely will add support for plain JS configs.
Agreed with the complexity added.
I wish package.json was package.js so that we could easily extend it, similarly to what we do with webpack.config.js.
I feel that adding script config to the package.json is great for standalone projects, but sharing is a challenge, not even talking about future updates that you have to tell folks "please open your package.json and update the following script config".
Thanks for sharing the child process info. I'm investigating it now. This is the last item on my list before we go all in with Jest and Grommet 馃拑
@alansouzati jest.config.js are coming for sure! :)
@alansouzati what did you end up doing?
Most helpful comment
@alansouzati
jest.config.jsare coming for sure! :)