Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
@TeachMeCode its a pain to setup typescript and once you managed to get typescript running and then do the next step and add jest, you realise its not working. You fix jest and then typescript runtime without jest doesn't work. At least for typescript the configuration options are reasonable and well-designed, but jest is crazy!
-
@devRancid ah interested, did search for jest alternatives, but this one I haven't come across yet. Does it still have the module-mocking craziness inbuilt like jest has?
-
@devRancid can it be disabled?
-
@devRancid vitest works like a charm. thanks for the tipp.
-
@c3r38r170 it really comes from deep frustration.
vitest works really nice now, but I am concerned that unless there is something about ECM that I don't know about, that makes module mocking with ecm really easy, I fear that vitest will eventually go down the same abyss as jest once the JS community invents a newer module loading system.
What only relying on JavaScript for HTML form input validation looks like
Found something true as 1 == 1
!RANT
Oh, the SORROW that is JEST! 😡
Endless days have been swallowed by the abyss in my quest to configure Jest with TypeScript and ECMAScript modules instead of CommonJS. Triumph seemed within my grasp until - BAM! - suddenly the tool forgets what "import" or "export" means. And the kicker? On the CI, it still runs like nothing’s amiss!
Allow me to elucidate for the uninitiated: Jest is supposed to be a testing safeguard, a protective barrier insulating devs from the errors of their peers, ensuring a smooth, uninterrupted coding experience.
But OH, how the tables have turned when the very shield becomes the sword, stabbing me with countless, infuriating errors birthed from Jest’s own design decisions!
The audacity to reinvent the whole module loading process just to facilitate module mocking is mind-boggling! Imagine constructing an entirely new ecosystem just to allow people to pretend modules are something they're not. This is not just overkill; it's a preposterous reinvention of a wheel that insists on being a pentagon!
Sure, if devs want to globally expose their variables, entwining everything in a static context, so be it. BUT, why should we, who walk the righteous path of dependency injection, be subjugated to this configured chaos?!
My blood boils as the jestering Jest thrusts upon me a fragile, perpetually breaking system, punishing ME for its determination to support whole module mocking! A technique, mind you, that I wouldn’t touch with a ten-foot pole, because, you know, DEPENDENCY INJECTION!
Where are the alternatives, you ask? Drowned in the abyss, it seems! Why can’t we embrace snapshots and all the delectable integrations WITHOUT being dragged through this module-mocking mire? Can’t module mocking just be a friendly sidekick, an OPTIONAL add-on, rather than the cruel dictator forcing its agenda upon our code?
Punish those clinging to their static contexts, their global variables – NOT those of us advocating for cleaner, more stable practices!
It’s high time we decouple the goodness of Jest from its built-in bad practices. Must we continue to dance with the devil to delight in the depth of Jest’s capabilities?
WHY, Jest, WHY?! ðŸ˜
rant
jest
js
commonjs
unit-test
typescript
ecm
mock