91–100 of 101 posts
Earlier quoted context omitted.
I can't tell how this has actually improved upon existing options like Koa. This reeks of object oriented programming just for the sake of object oriented programming.
Odd. Most people I know are trying to avoid OOP, particularly in the JS community.
Earlier quoted context omitted.
expect(me).to.barf.when(i.see(shit.like(this)));
It’s great for tab completion and can be very smart about types, and newer ones like jest don’t have excessive chaining style. Less bad than it used to be
assert(Object.is(foo.bar(), baq));
(where assert is magic that fails woth a friendly message when it's argument is falsy.
Earlier quoted context omitted.
While I wasn't aware that Deno was owned by a for-profit company, Deno itself is MIT licenced. Is there any particular reason why everything you just said cannot also be true for Deno?
I'm not exactly what I said about NodeJS that could apply to Deno. > NodeJS is a FOSS project under the Linux foundation Deno is not maintained by a non-profit organization, and Deno Land Inc are unlikely to want to let someone else control their project, that'd be kind of suicidal. > is not driven by profit The organization who maintain Deno is explicitly for-profit, meaning it has to be driven by profit. If they gi…
But it shouldn't matter whether or not they want it. You can fork Deno right now, change nothing but the name, and sell it as a commercial product. The MIT licence permits that. iirc SQLite is a private organisation that produces a public domain product. Should we quake in our boots and boycott SQLite? Nothing is stopping the proverbial io.js from drawing a line in the sand, forking Deno or SQLite, changing the name, and taking it from there.
EDIT: Similarly, React and React native are open source but controlled by Facebook. Swift is an open source programming language that's controlled by Apple. .NET Core is open source but controlled by Microsoft. Docker is open source but controlled by Docker Inc. MongoDB is open source but controlled by MongoDB Inc. GitLab is open source but controlled by GitLab Inc. OpenJDK is open source but controlled by Oracle. Redis is open source but controlled by Redis Labs.
What is the standard web application backend framework for Node.js these days, is it Koa? As I understand it express is quite dated because of the callback structure. I have been confused recently with the moving best practices. What is the server architecture Next.js is most often plugged into?
fastify https://www.fastify.io/
nest.js https://nestjs.com/
hapi.dev https://hapi.dev/
Earlier quoted context omitted.
It’s great for tab completion and can be very smart about types, and newer ones like jest don’t have excessive chaining style. Less bad than it used to be
What's wrong with ordinary expressions? That's discoverable too, and you often don't need any discovery cause it's the same code you write normally. assert(Object.is(foo.bar(), baq)); (where assert is magic that fails woth a friendly message when it's argument is falsy.
If you expect `assert(...)` to be magic enough to provide diffing and smart error messages because it's actually some kind of macro... then I guess we have different views on magic.
My point about completion is that if you do expect(a). with a smart library, the library can complete the list of assertions that apply to the type of `a`. Eg, if `a` is an Iterable, a good assertion library could complete `expect(a).toInclude(`. Jest doesn't do type-narrowed assertions (sad) but it could.
Earlier quoted context omitted.
What's wrong with ordinary expressions? That's discoverable too, and you often don't need any discovery cause it's the same code you write normally. assert(Object.is(foo.bar(), baq)); (where assert is magic that fails woth a friendly message when it's argument is falsy.
Everyone replaces `assert(isTrue: boolean)` with more specific assertions so that failures can produce helpful and specific error messages; something like assert.isEqual(a, b) can at least print a and b, but ideally can print the difference between a and b (which Jest does) -- where all `assert(a == b)` can produce is "Oops, assertion failed at line XYZ". If you expect `assert(...)` to be magic enough to provide diff…
The macro isn't deeply magic, it just prints the text of the tokens passed to it (ie foo.bar()) alongside the value. assert_eq can add a diff.
Sure the error message isn't perfect, so you stick a console.log or two in your test and run it again if you're confused.
Earlier quoted context omitted.
Everyone replaces `assert(isTrue: boolean)` with more specific assertions so that failures can produce helpful and specific error messages; something like assert.isEqual(a, b) can at least print a and b, but ideally can print the difference between a and b (which Jest does) -- where all `assert(a == b)` can produce is "Oops, assertion failed at line XYZ". If you expect `assert(...)` to be magic enough to provide diff…
I'm perfectly happy with assert and assert_eq. The macro isn't deeply magic, it just prints the text of the tokens passed to it (ie foo.bar()) alongside the value. assert_eq can add a diff. Sure the error message isn't perfect, so you stick a console.log or two in your test and run it again if you're confused.
Falling back to manual debugging is essentially admitting the test framework isn't helpful.
I think expect(a).toXXX(b) will provide better velocity for most engineering teams. I'd rather see a detailed failure message at the end of a 15 minute CI run than an unhelpful one that needs code edits to understand. Especially as the team & codebase have grown, I've found the detailed failure messages helpful when people ask for assistance – experts are more likely to figure things out on sight, turning tens-of-minutes-to-resolve into seconds-to-resolve.
With testing built into core, I’m looking forward to the reduction in complexity and number of external testing frameworks. I generally chose tape/ava in the past and vitest these days, but it’s awesome that now a very simple testing mechanism is available in core
Same. Every time I dive into a repo using Jest it infuriates me. So slow. The built in test runner is great.
Another reason Jest is slow is due to how it's usually configured to build code using Babel or tsc. Like vitest, you can configure Jest to use esbuild which makes it much faster than using Babel or tsc.
I am not a big Jest fan, but it seems like the most pragmatic test runner when you have 100+ engineers working on a project.
Earlier quoted context omitted.
A shame it's not using `expect` syntax, which recently was also adopted by bun.
Well I'm sure they knew about it -- maybe there's an impassioned debate on a GH Issue/Discussion somewhere on why they left it out. The refactoring of expect to a reusable library (that hopefully everyone could depend on) would be awesome as well. AFAIK there are multiple expect() implementations out there right now, would be nice if there was one.
Currently I use vitest and https://github.com/jest-community/jest-extended which gets you a reasonable amount of usable matchers.