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
Search - "commonjs"
-
Grunt, gulp, bower, webpack, rollup, yarn, npm, requirejs, commonjs, browserify, brunch, rollup, parcel, fusebox, babel,
wrappers for bundlers, frameworks on frameworks, then for css, theres scss, sass, less, stylus, compass, and for templates, handlebars, mustache, nunjucks, underscore, ejs, pug, jade, and about five billion other word-salad tools, all with their own CLIs, each in some way building on npm, but with their own non-congruent little syntax, like no one realized they were reinventing the same problems introduced by domain specific languages, most happy to announce "configuration takes a little time, but it's worth it!"
No, it's not. Just stop people. Just stop. You're not doing anyone any favors by creating another lib, all you're doing is tooting your own horn and self promoting. Use what exists and stop creating more shit for new people to learn, to add to the giant clusterfuck that is the 2019 hotmess known as "web development."
You're not special. You're not important. You're lib or tool will be famous for 15 minutes and no one cares what you've made.
If you want to contribute to web development, do us all a favor and contribute to global sanity by kindly deleting your contribution and any plans to contribute new solutions to problems that have already been solved.18 -
I learned today I can "npm install" directly from a GitHub repo. This allowed me to create a React component (viewer of gLTF files) for a 3D game and share it with my team. I know I could've published it to npm registry, but I didn't want that since it's a very specific component for our project, and private npm packages are very pricy.
Hope this random !rant will be useful for someone wanting something similar. -
!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?! 😭9 -
hey, i've got an idea
let's make the package format for browsers completely different than that of backend projects
fucking brilliant!
🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡19 -
so my suspicions were correct... most projects were fake and i was selected as a finalist for that hacking project!!!
wahoooooooo
also, day 5 of not knowing how to mix ES and commonjs packages in node
dutifuly signed,
🤡7 -
NodeJS’s transition from CommonJS is still a bit of a mess. Jest is the most used unit testing tool, but you need to fondle its balls to get it to work with ESM. Jasmine is the only major testing framework to support ESM out of the box. Luckily, jasmine is actually really nice.4
-
So I finally gave up trying to get TypeScript ES6 modules to work. Back to CommonJS it is, because fuck me I guess. I mean it *did* work... Until I also had to use a commonjs module at which point tsc basically tells you to fuck off with that2
-
Hello, a question about Node project -
How to import node libraries only once and use them all over the project.
I have asked it on StackOverflow, link to it
https://stackoverflow.com/questions...
If you guys have any idea for it, please, share!15 -
Many people in this world are worthy of being hated, but few are as irritating as the mongrels pushing for import\export to be used in backend projects. Breaking compatibility and bothering developers just because you can. Worst thing, they'll also probably win.