chore(toFetchHandler): allow HTTP/1 handler type

[kricsleo]

resolves #149

This is a type-only compatibility improvement for the toFetchHandler utility, making it compatible with libraries that only support HTTP/1, e.g., express.

Summary by CodeRabbit

• Refactor
  • Extended adapter support for additional Node.js HTTP handler configurations.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

📝 Walkthrough

Walkthrough

The PR adds TypeScript support for Node.js HTTP/1.x handlers by introducing a NodeHttp1Handler type alias and expanding toFetchHandler to accept either traditional Node.js HTTP handlers or HTTP/1.x-style handlers, resolving type incompatibility with Express.

Changes

Cohort / File(s)	Summary
Type Handler Support src/adapters/_node/adapter.ts	Introduced NodeHttp1Handler type alias for HTTP/1.x handlers; expanded toFetchHandler parameter type to union of NodeHttpHandler | NodeHttp1Handler; added typed NodeHttp import

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• #151: Modifies type declarations in the same adapter file and exports AdapterMeta—related type system updates in a shared module.

Suggested reviewers

• pi0

Poem

🐰 A hop, a bound, through types we weave,
Express now dances, sure reprieve!
HTTP/1 and traditional meet,
Handler unions make the feat complete! ✨

Pre-merge checks and finishing touches

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: allowing HTTP/1 handler types in toFetchHandler, which is the primary objective of the PR.
Linked Issues check	✅ Passed	The PR addresses issue #149 by expanding toFetchHandler parameter types to accept NodeHttp1Handler, enabling Express and other HTTP/1-only libraries to work without type errors.
Out of Scope Changes check	✅ Passed	All changes in src/adapters/_node/adapter.ts are directly scoped to resolving the type compatibility issue for HTTP/1 handlers as specified in issue #149.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/h3js/srvx@154

commit: 67f0302

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

src/adapters/_node/adapter.ts (1)

45-48: Consider adding JSDoc for the new type.

The NodeHttp1Handler type definition correctly represents Express-style handlers. Consider adding a brief JSDoc comment to document its purpose for future maintainers.

📝 Optional: Add documentation

+/**
+ * Node.js HTTP/1.x handler type for compatibility with libraries like Express.
+ */
 type NodeHttp1Handler = (
   req: NodeHttp.IncomingMessage,
   res: NodeHttp.ServerResponse,
 ) => void | Promise<void>;

📜 Review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 879ab07 and 67f0302.

📒 Files selected for processing (1)

• src/adapters/_node/adapter.ts

🔇 Additional comments (2)

src/adapters/_node/adapter.ts (2)

1-1: LGTM!

The type-only import is appropriate for defining the NodeHttp1Handler type and adds no runtime overhead.

---

54-69: The type union addition is safe. While NodeHttp1Handler is cast to NodeHttpHandler on lines 62 and 66, both handler types are compatible at runtime because WebIncomingMessage extends NodeHttp.IncomingMessage and WebServerResponse extends NodeHttp.ServerResponse, which satisfy both signatures. The actual objects passed to the handler are always HTTP/1 types, making the cast valid.