22 ms·
Meta Is Transferring Jest to the OpenJS Foundation
- jvalencia 4y agoMe putting my cynic's hat on, I wonder if Meta is trying to offload as much responsibility given recent belt-tightening?
- vjeux 4y agoI'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.
- jimmy2020 4y agoDoes Meta contribute financially to the foundation?
- rickhanlonii 4y agoMeta 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!
- deleted 4y ago[deleted]
- lloydatkinson 4y agoIs 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?
- edgyquant 4y agoFacebook created jest dude, they’ve invested more than that 26,000. That’s also almost half of the total donations.
- MoSattler 4y agoI 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?
- theptip 4y agoFacebook built this, with engineers that they were paying a salary to. It’s 100% industry-funded.
- samhw 4y agoI think they meant 'the rest of the industry'?
- MoSattler 4y agoExactly
- theptip 4y agoWhy 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.
- vjeux 4y agoMeta has contributed $22k to the Jest open collective which currently sits at $65k. https://opencollective.com/jest https://opencollective.com/jest
- duxup 4y agoI don't know. But even if that was the case is it cynical or just the right thing to do if you've got fewer resources?
- bennettdams 4y agoFacebook stopped actively maintaining Jest months (years?) ago, so this is a good move for the community. See this old HN thread: https://news.ycombinator.com/item?id=30168241 https://news.ycombinator.com/item?id=30168241 ..and the comment from the "only" remaining maintainer: https://github.com/facebook/jest/pull/11529#issuecomment-1027152470 https://github.com/facebook/jest/pull/11529#issuecomment-102...
- deleted 4y ago[deleted]
- rickhanlonii 4y agoI 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.
- jimmy2020 4y agoIs Meta moving away from Jest or is it still used internally?
- rickhanlonii 4y agoYeah, 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.
- ramesh31 4y ago>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?
- zpao 4y agoRome is a completely separate project that Meta no longer owns. You can check https://rome.tools/ https://rome.tools/ for the project status.
- 999900000999 4y agoI'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.
- azangru 4y agoIf only it could speed up whatever it is in the Node project that is blocking Jest's adoption of ES modules, including their mocking :-(
- edgyquant 4y agoYeah coming from python and pytest jest has been a real struggle to get right.
- steve_taylor 4y agoI 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.
- jdorfman 4y agoGood. Next should be React.
- jimmy2020 4y agoDo you think React will survive without Meta?
- k__ 4y agoThere are projects with smaller communities than React that do pretty well.
- jimmy2020 4y agoI know. But it's not just about the community it's more about the commitment and consistency.
- TAForObvReasons 4y agoThere are smaller projects not backed by a large tech company that arguably have more commitment and consistency.
- gherkinnn 4y agoVue survives just fine. 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] 0 - https://router.vuejs.org/ https://router.vuejs.org/ 1 - https://pinia.vuejs.org/ https://pinia.vuejs.org/ 2 - https://vitejs.dev/ https://vitejs.dev/ 3 - https://vitest.dev/ https://vitest.dev/
- nsonha 4y agoreact 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).
- bilalq 4y agoJest 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/ https://vitest.dev/ The `--ui` flag showing a visualization of the dependency graph of a test is probably my favorite little feature.
- yboris 4y ago+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.
- throwanem 4y agoCan you use Vitest without Vite? It looks cool, I'd love to know more.
- kasbah 4y agoI'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 https://github.com/elpnt/nextjs-vitest-example
- chain-- 4y agoYup I've used Vitest without Vite for a personal project. I replaced Jest as I was having a lot of trouble with ESM modules (it might be better now)
- throwanem 4y agoThanks! I'll definitely take a closer look - "better than Jest" is a great place to start, but not if it means boiling an ocean first.
- 4y ago
- jmull 4y agoIf I know mocha is there any reason I should learn and use jest? (outside of a React project)
- FinalBriefing 4y agoI 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.
- no_wizard 4y agoIf 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. Jest is also better in monorepos IMO.
- lloydatkinson 4y agoWe 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.
- skybrian 4y agoOff-topic but maybe here will knows: I like to use simpler tools, so I'm wondering if there's a more stripped down test tool, sort of like Preact versus React? For node-based testing I like Ava, but is there a simple tool for browser-based testing?
- koshergweilo 4y agoDepending on your stack vitest is pretty straightforward
- cute_boi 4y agoWasn'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
- debug-desperado 4y agoIs that like the Apache graveyard but for node projects?
- szundi 4y agoMaybe related to the engineer hiring freeze
- symlinkk 4y agoI wonder when they will do the same for Flow. The Flow VSCode extension is already abandoned - https://github.com/flow/flow-for-vscode https://github.com/flow/flow-for-vscode
- orta 4y agoI 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.
- eyelidlessness 4y agoI’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.
- cpojer 4y agoHi! 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. If you care more about raw performance and ES module support and less about isolation, check out the jest-light-runner: https://github.com/nicolo-ribaudo/jest-light-runner https://github.com/nicolo-ribaudo/jest-light-runner We also mentioned it in our Jest 28 blog post: https://jestjs.io/blog/2022/04/25/jest-28 https://jestjs.io/blog/2022/04/25/jest-28 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.
- matdehaast 4y agoI 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.
- muthannaKhaled 4y ago