I started as a Jest core contributor before joining Meta. It's arguably the reason I work there now, and I'm really excited for the move.
Meta created Jest and a lot of the features that it's known for, but it's true that it hasn't been invested in for a few years and most of the recent features were created by the community.
With this move, Meta is showing their commitment to Open Source and Jest will be able to grow with ownership through the OpenJS Foundation led by the Jest core team and the Jest community.
It reminds me of projects being moved to the Apache foundation, that too often felt like an obituary of sorts. I'm sure there's good stewardship of those projects at Apache, but nothing exciting to come out of it.
And it's a shame. I wish there were more of these big companies that would just, idk, pay an organization like Apache or in this case OpenJS so that they can operate as a software development and open source stewardship company, pay people to work and manage these projects.
It's not about money. Foundation stewards without any attachment to the project are like political appointments; no skin in the game. Money doesn't push a projects requirements and demand it continues to evolve, diverse users do.
Sending it off to the Apache foundation in this state to me sends a signal that it's good enough, innovation is no longer required, and therefore is not worth the investment to continue to maintain.
It's going to take a while to impact the current ecosystem but NodeJS is implementing testing natively and that will inevitably erode the popularity of jest/mocha/etc -
It will have some impact, but that erosion will be limited by how readily portable it is (I’d assume very, but haven’t looked at the source) and how attractive a target it’ll be for abstractions.
The former is table stakes if it has any chance of displacing test frameworks which are already widely used for both server and client code. I would be shocked if it’s an issue though, there’s very little to gain from coupling a test framework to Node specifics (its own non-test APIs, V8 bindings, NAPI, etc) unless you’re heavily invested in that focus. (I say this as someone who’s worked on such a project off and on for a while, and even then the primary motivation is to make testing itself more portable without sacrificing performance or tooling.)
The latter—attractiveness as a low level API to build on—remains to be seen. This is something Node generally does well with its novel APIs. But it’s a very crowded space already. And from what I’ve seen looking at the APIs, they don’t offer a whole lot more than basic correctness that can be skipped to quickly prototype and iterate abstraction ideas.
Otherwise it’ll be a reasonable default for very Node-specific greenfield projects. Which is welcome! But it’s also a somewhat niche audience. Portability is going to matter to almost all Node users already, and abstraction will matter to a largely overlapping segment of users who are accustomed to a much richer set of built in and extensible testing semantics.
I don’t want to dismiss the effort or its prospects outright! I just think it’s become increasingly clear that Node’s influence relative to the JS ecosystem is shrinking as the diversity of runtimes increases and as compatibility between them becomes more important.
Yeah, Meta will continue to use Jest internally. It still works really well for us, it's just "feature complete" for our use cases so we haven't needed to invest in it.
>Yeah, Meta will continue to use Jest internally. It still works really well for us, it's just "feature complete" for our use cases so we haven't needed to invest in it.
What's the status of Rome? Is that being looked at as a long term replacement?
I'm a mixed of confused and optimistic about this project.
On one hand, I would absolutely hate for someone to force me to use one tools, opinions for everything I do in a project.
On the other hand, if I just start a new job and I need to get producing, I'd rather have one big tool that just makes JavaScript work. Versus 4 different tools with a bunch of different limitations.
I have full confidence that the people working on it can deliver an incredible product. I have severe doubts that this will be sustainable as a business though, which really sucks
Jest has been pretty wonderful to work with over the last few years. Like any test framework, however, there are real pain points.
I've recently started experimenting with Vitest on a new webapp using Vite/React. It's API compatible with Jest, but integrates with your existing build tool-chain instead of forcing you to configure a parallel one. So far, there's a lot to like.
https://vitest.dev/
The `--ui` flag showing a visualization of the dependency graph of a test is probably my favorite little feature.
I've been leading the adoption of vitest at my company. It's not perfect, and there are some bugs but the performance gain is truly incredible. We have about 150 snapshots for various UI components and vitest can crunch through all of them in about 5 seconds, whereas it would take Jest 3-4X that time.
It's also nice if you're running a "vite stack", you don't have to pull in babel and a bunch of other libs just to make Jest work.
Do you feel the snapshot tests are useful? I've mostly had bad experiences with them (mostly noise), so interested in hearing what makes them work for you/others.
I (weirdly) got sold on snapshot tests while developing a tree-sitter grammar. They don’t make it super obvious (and most snapshotting test solutions don’t) that you can “update all”, but the workflow makes more sense to me now that I’ve even generated my test cases from a more intentional suite. The goal is for it to be noise! It’s entirely a regression test, and it should alert you if you changed something without knowing you did. But it’s only valuable if you snapshot test the things you expect to be stable, write specific tests for the changes you intend to make, and compare between them.
Their not that terribly useful. We have already been talking about replacing them with proper unit tests. One thing they are very useful for is being a cheap way of showing non-technical leadership that you have "100% test coverage".
I only have a handful of Jest unit tests, but they each take nearly 30 seconds nowadays and I don't really know why. Maybe because everything is wrapped in a Formik top level tag? Maybe it somehow pulls in and executes all my code multiple times over? There's probably something silly going on there.
Anyway as just the one developer on this project, I don't see the value in writing unit tests for every one of my components. They just work, I'll leave them alone for a few years until someone else builds a new UI.
I'm pretty sure you can. Though I haven't tried it myself I did a search if we could integrate it into our Next.js app (Next uses Webpack internally) and found this: https://github.com/elpnt/nextjs-vitest-example
Vitest is great for running unit tests, but for component testing I still think running in a real browser and using visual snapshots & diffs is preferable to dom snapshots & diffs in a fake browser env like node + jsdom.
It's not just the fact that jsdom doesn't fully support all browser APIs, but components are building blocks for a primarily visual medium, so being able to build and debug my component tests visually has been a complete game changer when it comes to productivity.
I think the very reasonable counterpoint to that is browser tests are slow to run, to the point that it's infeasible to run locally at scale. That's why for https://reflame.app, I've been building a testing strategy around using serverless compute to run browser component tests with maximum parallelization for a tight feedback loop that takes ~5s for a cold start and 1~2s thereafter, with dependency analysis to rerun only tests that could have changed to keep cost scaling under control.
+1 for vitest & vite -- used both as the foundation when porting over a few custom elements and it's a pleasure working with them. Migrating tests from Jest to vitest required almost no changes.
I’m not a fan of Jest, but this is good news anyway. If nothing else, establishing clear dedicated stewardship is a great chance to see if some of its limitations can be overcome.
I don’t mean to criticize anyone’s prior work but I know it’s better to be more specific, so my short list of problems I’ve experienced with Jest and reasons I won’t consider it for projects currently:
- Its mocking model is coupled to CJS semantics and static analysis and hoisting patterns built on Babel, and it’s hard to work around that especially in legacy code.
- Its isolation model is inherently prone to memory leaks and fragile tests, directly related to the above point. If you `import 'anything'`, in a test module or its dependency tree, you might think you’re initializing once but you’re initializing for each test. If that initialization even exposes a way to teardown it’s just sitting there waiting for you to know you need it in an afterEach, otherwise they run perpetually and never get GCed. Really surprising things like loggers and other seemingly passive libraries which you might develop internally suffer from this. This might all sound like whining, but it can make a large test suite basically useless because you can’t even observe the code that’s still running.
- I’ve watched ESM support improve and I’m impressed by the effort, but from my observation the above issues are major barriers to making its mocking and isolation strategies viable. ESM isn’t the reason they’re challenging, but cache invalidation of stateful imports is an exceedingly good way to reveal them.
Hi! Christoph from Jest here. Your feedback is great, and 100% valid. Jest was built a long time ago when ES modules did not exist, and we are still carrying some of that legacy baggage around.
The good news is that we have never been shy about making breaking changes and we are working on cleaning the house and making many legacy components optional, all while bringing the existing community with us.
As for mocking, you don’t have to rely on Jest’s inbuilt mocking libraries and you can use the ones you like better.
I’m wondering if it’s time to consider taking a big step and making this runner the default, and give people the optionality of isolation. However, in my past experience at large companies (both first-hand and second-hand experience), the lack of isolation in tests led to major reliability problems with testing infrastructure. I’m still feeling like it’s the better default today, but maybe we should have a serious discussion about Jest’s next set of defaults.
> As for mocking, you don’t have to rely on Jest’s inbuilt mocking libraries and you can use the ones you like better.
I was preparing myself to reply “thanks for the kind and receptive response, but…” I’m glad I read further before drawing a conclusion.
> The good news is that we have never been shy about making breaking changes and we are working on cleaning the house and making many legacy components optional, all while bringing the existing community with us.
> If you care more about raw performance and ES module support and less about isolation, check out the jest-light-runner
It looks likely this addresses the problem I was going to raise! I never wanted to use module mocking in the first place, and never did. But Jest at the time I used it didn’t give me an option to opt out of its isolation model and still imposed all of the problems whether I used module mocks or not. I think this (runner which doesn’t support it) is a great thing to provide, and yeah if you’re okay with breaking changes it’s a much more sensible default.
Thank you for not just the kind and receptive response, but also for showing clear direction from problems I raised! I’ll keep tinkering on my test framework as a hobby project because there are already major perf and semantic wins in it. But this definitely makes Jest a more viable day work consideration for me.
Edit to clarify: I agree isolation between tests is crucial, and isolating modules is an important part of that. It’s just… not what Jest is actually doing. It wasn’t when I was using CJS, and it’s much more challenging to mitigate with ESM. Jest very reasonably clears the require cache between tests, but that’s actually breaking isolation when modules have private state initialized on require. If I remember correctly the ESM solution is the same as my naive one: tack a query parameter on when re-importing.
Realistically, the only current viable solution to isolation is worker threads and WASM/NAPI hacks. Hopefully better isolation primitives are coming up through the standards process.
That seems great, definitely going to check it out!
Do you know if there's a way to use that runner per-file or per-project within jest? Seems like that's the only way it'd be possible to smoothly migrate in a large codebase without rewriting all tests at once.
Jest supports multiple “projects” in a single invocation, and they can all use a different reporter.
You can define a base config for your repo, and then inherit two sub-configs from it each with different runners and mutually exclusive selection for tests (by suffix, folder, or any convention that works for you).
Thank you! We actually do use the "projects" feature, but we've found a fair number of options don't work when defined at the project level (a good example is `coverageThreshold` - we weren't able to make per-project thresholds work, at least in jest 26).
Glad that this one has the ability to be configured more granually - that'll come in handy for migrating gradually.
I recently started using unstable_mockModule quite heavily. It works well. The only thing missing is importActual, but in most cases, requireActual will do the job.
As far as I know, further development is on hold until Node’s VM modules feature stabilises. I believe Node is waiting on V8.
I've been involved in making this move happen and it has been many months in the process and was many years overdue. The two events, at least from my perspective, are unrelated.
Meta is a backer of the Linux Foundation which OpenJS is a part of and has donated $22,000 to the Jest Open Collective which was created by Meta in 2016 to support non-employee Jest contributors. Jest actually has all the funds we need right now and our bigger issue is finding ways to spend it!
Is that it? Facebook is a huge corporation, that must have React app after React app using Jest, and they are paying volunteers to work on it now? With a fraction of what a single developers average salary is?
They are providing their code to you free of charge. They are already doing you a kindness. So certainly they are under no obligation to spend $22k, let alone more than that. Christ, attitudes towards open source have become seriously warped over the last few years.
I will point out, as an open source maintainer: someone giving you code "free of charge" is the same thing as them giving you a free puppy: everybody loves puppies, but they are absolutely not free to maintain.
This isn't meant to imply that Meta is, in this instance, offloading costs onto the community. But it's a tried-and-true tradition.
A white elephant, basically, you mean? I definitely understand that, but I'm not sure it applies here. Jest and React are exceptionally mature and well-maintained pieces of software. Many a startup has been built by gluing React to Express and Postgres with nary a glimmer of skill required. Hell, it has its own developer tools built into Chrome.
The pernicious thing about "mature and well-maintained" pieces of software is that their maintenance becomes bursty: they don't need anything for years, until something needs changing/fixing this instant.
Log4j is the canonical example of this: it's such a boring piece of substrate that nobody noticed that it was effectively maintained by one person and had grown all kinds of configurable knobs and dials over the years.
Ultimately, I'm not saying that Meta is in the wrong here. But "here's a cash infusion with no long-term funding or staff commitment" is the kind of general mispattern that we're seeing w/r/t corporate open source.
I just don't see how it's less valuable than not using it. That seems analytically true to me: if ever the debits do outweigh the credits, then one simply doesn't use it. After all, it's not like it's a library doing some magical thing; it's a framework which operates on code written to a certain interface, and for which alternative 'compilers' (e.g. Preact) already exist.
And? They were presumably paying at one point their own developers full time salaries while working on Jest and now Jest has been cast off to somewhere else and suddenly any expected future contributors deserve, in comparison, pennies? All while still using Jest themselves internally.
> any expected future contributors deserve, in comparison, pennies?
No, they don't deserve pennies. Facebook has given its code to the world - if anyone wants to keep that code maintained, then they can do so, but (I'd have thought needless to say) Facebook does not owe them a penny to maintain it just because they were kind enough to donate that version of their code. They can update it if they benefit from doing so.
Seriously, is this where we've got to? You can't open source your code unless you're able to pay for its maintenance in perpetuity? How is this in the spirit of openness? And, more to the point, how in the hell does this (incomprehensibly entitled) attitude encourage open source development?
And good for them, but that doesn't affect the fact that they are doing you (/me, us) a favour, an act of supererogation.
In any case, my point isn't really about whether they are being kind or not. That's a fortiori. It's that they certainly aren't under any obligation to provide it, nor to maintain it on account of having provided it.
(Although to respond to your precise point: I'm severely doubtful of your claim that Facebook gets 'huge marketing PR' from an open source library. No one is signing up to Facebook because of the [apparently-existent] 'huge marketing' of the fact that they wrote React.)
This isn't some_one_, it's some_thing_. I share your sentiment when it comes to individuals but extending the same sympathy to a company, especially one the size of Facebook, doesn't make sense imo.
It's not a question of 'sympathy', it's a question of recognising the neutral fact that a company providing its code to you free of charge is not further obligated - irrespective of whether you happen to like or dislike that company - to spend what you deem to be an 'appropriate' amount on maintaining the free software they provide you.
(And, even if any of the foregoing made any sense, the notion that an 'appropriate' amount is somehow measured relative to the company's revenue, rather than the factual costs of maintaining the software, is disqualifyingly silly in its own right.)
This isn't some random small library. It is/was a library developed by a FAANG company that underpins a large part of the JS ecosystem that they were paying their full time employees to work on.
I didn't know they had so little donations. It's a super important building block of the industry, and yet the industry doesn't even pay a single developers salary for it?
Why would anyone else in the industry contribute resource to a FB-owned project with closed governance? They are in the bottom five companies in the world that need help with the open source projects they maintain.
I get what you are lamenting in general, I would like to see OpenSSL or Django or perhaps even Linux better funded for example. It just seems to me that this is not a case where any lamenting is justified. If the newly-community-owned Jest doesn’t get investment, then sure, that would be lamentable. But that hasn’t happened yet. Indeed, FB divesting ownership was a necessary condition for any serious outside investment to occur, IMO.
I was talking about the Linux Foundation of the original comment.
Now reading back, I realise that I might have gotten confused and took the numbers that were referring to the Facebook project, thinking it was the Linux donations.
I just want to call out my great appreciation for Simen. He has been trying to maintain the fort of Jest for years. He is not even a Meta employee. Releases would always be complicated and blocked as Meta needed to sign off. I'm glad this is moving and hopefully more velocity can happen within Jest now.
We will have to wait a while to see where this leads. I hope it goes well but I am worried. I have started using Vitest on projects where I can recently anyway. For a very very long time Jest was holding up unit testing support for Vite to where point that someone else developed Vitest in the meantime.
I wouldn't use this as an indication of flow's usage, the extension switched to using an LSP so the majority of the work for dev experience happens inside the flow codebase nowadays.
If you don't plan on using it in the browser, it has everything Mocha does and doesn't, like built in expect functions (mocha only provides the runner infrastructure).
Its also, as of late, really shown some innovation around testing, I think Jest 28 is a huge step in the right direction.
The only other fully fledged alternative I can think of is Jasmine (which, iirc Jest is actually a fork of?) but Jasmine isn't as well maintained and has no transform infrastructure.
Basically, unless you're just really happy with mocha, I think Jest gives you more flexibility, especially as projects / products grow overtime.
I found it to be fast and easy to set up. I reviewed a number of testing frameworks for vanilla JS projects, and it came up on top, even though I hoped it wouldn't (I try to avoid all Facebook products).
I can't remember the specifics, but I think it was a mix of having nice reporting built in, easy to spy on or mock our ESModules, and there are a lot of other developers using it, so it was easy to find solutions.
It mostly "just worked" and didn't require adding other libraries to handle mocks and spies.
Wasn't facebook asking donations for Jest despite being billion dollar company? Couldn't facebook fund the development of Jest instead of asking donations.
(P.S. I don't know full story but 2 years ago I used to see sponsor button on opencollective for Jest. And, the repo actively mentioned jest is owned by facebook)9
Sure, its market share is lower, but the quality of Vue 3 is on par with React. Most impressively, it comes with its own core libraries for routing [0] and state [1]. And by extension, has spawned library agnostic tooling in the form of Vite [2] and now Vitest. [3]
react also survivED just fine, but they will die eventually, and because of the nature of front end development, it will happen faster than typical software project. It doesn't help that most veteran web devs hate react (vs the platform).
some one downvoted me because I said "veteran web devs hate react"? I'm just saying what I've seen, and while I no longer care for react as much as I did, it's still my favourite way of making front end apps.
I understand that people who live in twitter bubble or whatever don't like to hear opinions that pop it.
I do. The ecosystem is strong and if handed over to a foundation like the OpenJS Foundation it has a better chance of evolving. From my perspective, React is what FB/Meta needs, not necessarily what the community wants. There is no oversight or governance which is concerning given that many developers make a living off of React.
For an expanded explanation see YouTube/KTQVBXb0uPM?t=328
Meta created Jest and a lot of the features that it's known for, but it's true that it hasn't been invested in for a few years and most of the recent features were created by the community.
With this move, Meta is showing their commitment to Open Source and Jest will be able to grow with ownership through the OpenJS Foundation led by the Jest core team and the Jest community.