Jest: Split jest into smaller modules

[andrewdeandrade]

Can you split jest into smaller npm modules so others can use just the parts they need/want?

There are some parts of jest I would like to use in other tools, but the way its built at the moment make it a basically all or nothing solution. For example, package.json:main points at the binary instead of the jest library so you can require('jest'); (https://www.npmjs.org/doc/files/package.json.html#main)

AFAICT there are a few subcomponents that can be extracted:
(1) mocking utilities (the parts that when given a javascript object, analyze it and return a mocked object)
(2) the loader (jest's require() and extensions to require())
(3) mock timers
(4) the runner
(5) coverage stuff
(6) sugary stuff

I'm mainly interested in 1, 2 and 3, but do not want 4, 5 or 6 and definitely don't want anything that injects globals ever.

[jeffmo]

(1) Mocking Utilities - At some point I think it'd be good to explore Sinon for mocking utilities. I haven't looked in to this yet, though, so I don't know if there are any blockers here.

(2) The Module System/require() - There are quite a few requests to support module systems other than just the node-commonjs variant that we support right now. As part of solving that, I'd like for us to make the module system pluggable -- and eventually have these module system plugins exist as their own npm packages (where the current system is just a pacakge.json dependency in order to exist as a "sane default")

(3) Mock timers - My initial thoughts: It seems likely to be more work than it's worth to maintain a separate package for FakeTimers + express all of the (fairly jest-oriented) guarantees and features; Therefore I don't know if this would be a good idea or high value. If you feel strongly about this, I'd be willing to talk more about specifics if you could outline exactly what aspects want to use in isolation?

(4) The runner - This piece is really the center of the wheel spokes, so I don't think it makes sense to generalize here.

(5) Coverage stuff - Currently Jest just uses the cover package for collecting coverage info. The biggest issue at the moment is just finding a good way to surface that info (it needs to be available through the library APIs as well as the default CLI utility)

(6) Sugary stuff - Not sure what you mean by this, can you clarify? Do you mean things like syntax transforms for ES6/coffee-script/etc? If so, jest has no opinion on this -- but it does support pre-processor plugin scripts through the config.scriptPreprocessor config option

[benzen]

Packing 1,2,3 would make it simpler to maintain for Facebook people.
It wouldn't be an issue about updating Jasmine version.
Plus it will be usefull for everybody

[TheSavior]

@tomocchino This is the PR I mentioned about splitting things out.

[cpojer]

This is, at last, happening. We are filling up the new /packages/ folder: https://github.com/facebook/jest/tree/master/packages

Next up is the mocking feature, which will be launched as jest-mock, cc @abramovdmitrii
Alex Juarez has started refactoring Jest itself, which will make further work here easier as well.

[probablyup]

Highly recommend sinon for most mocking needs. It's an _excellent_ library.

[cpojer]

We have now split off jest-mock and the test assertion library plugins jest-jasmine1 and jest-jasmine2. We will continue making Jest more modular, which helps us rethink the boundaries of Jest and will eventually allow us to build cleaner APIs. While we haven't made everything modular, I think the original intent of this issue has been achieved and further work will be done in smaller internal/external tasks that are tracked individually. I'll close this issue but feel free to open new ones about things you'd like to be more abstract.