fix: make module import-safe in non-browser environments (SSR/Node)#38
Open
dmchaledev wants to merge 1 commit into
Open
fix: make module import-safe in non-browser environments (SSR/Node)#38dmchaledev wants to merge 1 commit into
dmchaledev wants to merge 1 commit into
Conversation
The README advertises `import { calculate }` as a "pure DOM-free
calculator" for Next.js/SSR, but importing the module in any non-browser
environment threw `ReferenceError: document is not defined` at load time,
before `calculate` was even reachable. Module top-level code called
`document.createElement`, subclassed `HTMLElement`, and invoked
`customElements.define` unconditionally.
Guard all three DOM touchpoints behind environment checks so the module
loads cleanly under Node.js/SSR/serverless/test runners while preserving
all browser behavior. Add a regression test that imports the module with
no DOM globals present (node:test isolates each file in its own process).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ni4iqvgAU45pJsxvcuwYth
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The README advertises
calculate()as a "pure DOM-free calculator" that works in Next.js and other bundlers:But importing the module in any non-browser environment (Node.js, SSR / React Server Components, serverless functions, edge runtimes, or a test runner without a DOM shim) throws at module-evaluation time — before
calculateis ever reachable:This happens because three pieces of module-level code touch the DOM unconditionally:
const TMPL = document.createElement('template')(top level)class HailbytesVulnCalculator extends HTMLElement— theextendsclause is evaluated at class-definition time, so it throws ifHTMLElementis undefinedcustomElements.define(...)(top level)The existing test suite passed only because both test files inject a global DOM shim before importing the module, masking the bug.
Fix
Guard all three DOM touchpoints behind environment checks so the module loads cleanly under Node.js / SSR / serverless / test runners, while preserving 100% of the browser behavior:
<template>element whendocumentexists.HTMLElementis unavailable.customElementsanddocumentare present.The
calculate()export is now genuinely DOM-free, as documented.Testing
test/dom-free.test.mjs— a regression test that imports the module with no DOM globals defined and runscalculate().node:testisolates each test file in its own process, so this exercises the real non-browser path (no shim leakage from the other test files).node -e "import(...)"with no shim now succeeds.🤖 Generated with Claude Code
https://claude.ai/code/session_01Ni4iqvgAU45pJsxvcuwYth
Generated by Claude Code