happy-dom

Happy DOM is an npm-published JavaScript library that implements the browser's document object model without any graphical user interface. It is intended to give JavaScript code a browser-like DOM environment, so scripts and components that expect document, window and related web APIs can execute outside a real browser. What it covers The project's README highlights DOM-focused capabilities it implements: - Custom Elements, i.e. Web Components - Declarative Shadow DOM - Mutation Observer - Tree Walker - Fetch API - and, in the maintainers' words, much more Because these are DOM-layer features rather than rendering features, the library targets programmatic use of a web page rather than visual display. That makes it a candidate for environments where a full browser or headless browser would be heavier than needed. What it works with Documentation lists a broad set of tools and frameworks the project states it is compatible with: - Test runners and testing utilities: Vitest, Jest, Bun, Testing Library - Frameworks and component libraries: Google LitElement, Vue, React, Svelte, Angular This range suggests the library is positioned less as a standalone application and more as a shared DOM substrate beneath other tooling, particularly front-end test setups. The README links directly to a wiki page about setting it up as a test environment. Documentation and community The project maintains a GitHub wiki with a documentation entry point, a getting-started page and a dedicated setup-as-test-environment guide. A contributing guide is available in the repository for people who want to send changes. The README also acknowledges sponsors, whose logos are displayed on the project page. Project details - Language and ecosystem: JavaScript, distributed through npm as happy-dom - License: MIT License, copyright 2019 to present, held by David Ortner - Repository: capricorn86/happy-dom Who it might suit Developers who want to run tests or execute DOM-dependent code in Node.js-based or Bun-based workflows, without launching a graphical browser, are the natural audience. Teams using one of the listed test runners or frameworks may find it worth evaluating as a DOM environment. As with any dependency of this kind, the practical test is whether the specific DOM features your code relies on are covered and behave as expected in this implementation. The README itself does not make claims about performance, benchmarks or completeness beyond the features listed, so those should be verified directly against the project's current documentation and test suite.