#JavaScript, such a lovely programming environment

Writing some unit tests for a **browser** app which must parse historic XML (WebDAV result) I stumble upon

ReferenceError: DOMParser is not defined

It would be no problem in the browser itself, but the tests were supposed to run without browser. And node has no DOMParser, I just learned.

No problem, jsdom seems to be the library to go with. But then: https://npm.anvaka.com/#/view/2d/jsdom

45 dependencies😱

#jsdom #unittest #domparser #node #browser

Over the last few days while working on an upcoming blog post I've performed quite the yak shaving:

1. I wanted to use `@layer` in a #CSS demo (ironically one showing that it doesn't solve this particular use case).
2. My auto #CSP setup using #JSDom and #CleanCSS failed to parse `@layer`.
3. I upgraded #CleanCSS.
4. I removed #JSDom and replaced it with #parse5, which works with `@layer`.
5. I wanted to use `Object.groupBy` here which requires `target: "ES2024"` in #TypeScript.
6. Therefore I needed to upgrade TS.
7. Upgrading TS broke #Karma for reasons I couldn't understand.
8. Therefore I migrated from Karma to #Vitest (which I've wanted to do anyways).
9. Now #Netlify is confused that I have both an 11ty and Vite project and fails, asking me to pick one.
10. I pick one in `netlify.toml`, but a bug in Netlify refuses to accept it.

https://answers.netlify.com/t/netlify-ignores-framework-configuration-and-throws-error-detected-commands-for-eleventy-vite/156020

#dev #web : je lance de plus en plus souvent mes tests avec #Deno plutôt qu'avec #NodeJs .

Pourquoi ? À cause d'un meilleur support des standards web.

Un truc tout con : si dans le code vous avec un truc simple comme ça :

globalThis.addEventListener('foo', e => {});

Bah ça plantera sous Node. Et pour que ça plante pas, faut charger un code tiers comme #JSDom .

Avec Deno, ça passe direct parce l'objet global implémente EventTarget, comme il se doit !

Ignoring JSDOM Errors in Vitest

When ignoring a problem becomes such a problem itself that you can no longer ignore it #tdd #jsdom #vitest

https://www.closingtags.com/ignoring-jsdom-errors-in-vitest/

👨‍💻 I'm building an app with as little #JavaScript as possible (only sending and receiving push notifications). I don't use any framework, and everything else is handled by the server.

❓ Now I'm wondering how to handle #testing. Does it make sense to do #UnitTesting for a few lines of JavaScript? How do you handle that? Do you only do #E2ETesting in such cases?

💭 I was already thinking about using #JSDom in #Jest, but the #HTML is generated by #Symfony, making it hard to get it in there…

Has anyone built a "headless browser" that can be bundled with a CLI tool?

I'm thinking jsdom (but probably built with Rust + WASM). Something that can render websites and execute JavaScript, but is super small doesn't ship any window chrome or keyboard input support etc?

Asking because someone managed to compile SpiderMonkey to Webassembly. https://github.com/bytecodealliance/spidermonkey-wasm-build 😍

#rust #wasm #jsdom

For the past few weeks I've been experimenting with setting up component testing on a #lit #webcomponents project. There is very little documentation on how to do it:

My solution was:
- #vitest for running tests and assertions
- #JSDom and open-wc/testing-helpers for component rendering
- shadow-dom-testing-library for DOM querying

I might write a blog post about it