feat(renderer): allow disabling renderer #3822

kricsleo · 2025-11-29T08:18:14Z

🔗 Linked issue

resolves #3818

❓ Type of change

📖 Documentation (updates to the documentation, readme, or JSdoc annotations)
🐞 Bug fix (a non-breaking change that fixes an issue)
👌 Enhancement (improving an existing functionality like performance)
✨ New feature (a non-breaking change that adds functionality)
🧹 Chore (updates to the build process or auxiliary tools and libraries)
⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

This PR enables disabling the default renderer feature using renderer: false.
(I didn't update the docs, seems like the doc is still WIP :)

📝 Checklist

I have linked an issue or discussion.
I have updated the documentation accordingly.

vercel · 2025-11-29T08:18:20Z

@kricsleo is attempting to deploy a commit to the Nitro Team on Vercel.

A member of the Team first needs to authorize it.

coderabbitai · 2025-11-29T08:18:25Z

📝 Walkthrough

Walkthrough

The changes implement support for disabling the renderer in Nitro configuration. A new optional property is added to the NitroConfig type allowing renderer to be set to false or configured as a NitroOptions renderer object. The path resolver is updated with conditional guards to skip renderer initialization when explicitly disabled.

Changes

Cohort / File(s)	Summary
Renderer configuration support `src/types/config.ts`, `src/config/resolvers/paths.ts`	Type definition updated to include optional `renderer` property supporting `false` value or NitroOptions renderer config. Path resolver adds guard to check if renderer is explicitly disabled and restructures template/handler resolution logic with inline conditionals and new branches for default template detection.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

src/config/resolvers/paths.ts: Multiple conditional branches and control flow restructuring warrant careful review—specifically the guard logic for renderer false case, inline conditional for template resolution, and new handler assignment logic
src/types/config.ts: Public API change to NitroConfig—verify union type accurately represents the intended behavior (false vs. renderer configuration)

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run `@coderabbitai generate docstrings` to improve docstring coverage.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title follows conventional commits format with a clear type (feat) and scope (renderer), accurately summarizing the main change of allowing renderer to be disabled.
Description check	✅ Passed	The description clearly explains the feature being implemented (disabling renderer via renderer: false) and references the linked issue, making it relevant to the changeset.
Linked Issues check	✅ Passed	The PR successfully implements the feature requested in issue #3818: renderer can now be set to false to skip default rendering, allowing requests to pass through to custom handling.
Out of Scope Changes check	✅ Passed	All changes are focused on enabling the renderer: false option across config types and path resolution logic, directly addressing the linked issue requirement.

✨ Finishing touches

📝 Generate docstrings

🧪 Generate unit tests (beta)

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

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between a5f4b2b and f4f6ff0.

📒 Files selected for processing (2)

src/config/resolvers/paths.ts (2 hunks)
src/types/config.ts (2 hunks)

🚧 Files skipped from review as they are similar to previous changes (2)

src/config/resolvers/paths.ts
src/types/config.ts

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)

GitHub Check: tests-rolldown (windows-latest)
GitHub Check: tests-rollup (windows-latest)

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

coderabbitai

Actionable comments posted: 0

🧹 Nitpick comments (1)

src/build/vite/plugin.ts (1)
88-111: LGTM! Client environment input correctly respects renderer configuration.

The cached nitro reference and conditional logic correctly prevent setting a client input when the renderer is explicitly disabled.

Minor consistency suggestion: Line 120 calls useNitro(ctx) again rather than using the cached nitro reference from Line 94. While this doesn't cause issues, using the cached value would be more consistent.

Optional refactor for consistency:
       environments.client = {
         consumer: userConfig.environments?.client?.consumer ?? "client",
         build: {
           rollupOptions: {
             input:
               userConfig.environments?.client?.build?.rollupOptions?.input ??
               (nitro.options.renderer === false
                 ? undefined
                 : nitro.options.renderer?.template),
           },
         },
       };
       debug("[env]  Environments:", Object.keys(environments).join(", "));
       return {
         environments,
       };
     },
 
     configEnvironment(name, config) {
       if (config.consumer === "client") {
         debug(
           "[env]  Configuring client environment",
           name === "client" ? "" : ` (${name})`
         );
         config.build!.emptyOutDir = false;
-        config.build!.outDir = useNitro(ctx).options.output.publicDir;
+        config.build!.outDir = nitro.options.output.publicDir;
       } else {

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 2989d6b and a5f4b2b.

📒 Files selected for processing (6)

src/build/virtual/renderer-template.ts (1 hunks)
src/build/vite/plugin.ts (2 hunks)
src/build/vite/prod.ts (1 hunks)
src/config/resolvers/paths.ts (1 hunks)
src/routing.ts (1 hunks)
src/types/config.ts (1 hunks)

🧰 Additional context used

🧬 Code graph analysis (1)

src/config/resolvers/paths.ts (2)

src/utils/fs.ts (2)

resolveNitroPath (14-32)

prettyPath (9-12)

src/runtime/meta.ts (1)

runtimeDir (10-10)

🔇 Additional comments (6)

src/types/config.ts (1)

86-86: LGTM! Clean type extension.

The type change correctly extends renderer to accept false as a value, enabling the feature to disable the renderer while preserving backward compatibility for undefined and object values.

src/routing.ts (1)

75-81: LGTM! Correct guard implementation.

The conditional correctly gates renderer route registration on renderer !== false, ensuring the renderer route is only added when the renderer is enabled and a handler exists.

src/build/vite/prod.ts (1)

55-77: LGTM! Template transformation correctly gated.

The guard ensures template transformation is skipped when renderer is explicitly disabled, while preserving the existing behavior for enabled or undefined renderer configurations.

src/build/virtual/renderer-template.ts (1)

13-23: LGTM! Clear renderer disablement logic.

The guard logic correctly handles the disabled renderer case by setting template to undefined when renderer === false and returning a no-template response. The explicit check on Line 17 for renderer === false adds clarity even though it's technically covered by the typeof template !== "string" check.

src/build/vite/plugin.ts (1)

393-405: LGTM! Default SSR renderer correctly gated.

The guard ensures the default SSR renderer is only activated when the renderer is not explicitly disabled, while preserving the existing conditional logic for handler and template absence.

src/config/resolvers/paths.ts (1)

136-180: LGTM! Comprehensive renderer resolution gating.

The guard at Line 136 correctly wraps the entire renderer resolution logic, ensuring no renderer-related processing occurs when explicitly disabled. The internal logic flow is preserved:

Handler resolution (Lines 138-146)

Template resolution with default fallback (Lines 149-170)

Default handler assignment when template exists (Lines 173-179)

The distinction between explicit false and undefined is correctly maintained, preserving default behavior when renderer is not explicitly disabled.

pkg-pr-new · 2025-11-29T08:22:04Z

Open in StackBlitz

npm i https://pkg.pr.new/nitrojs/nitro@3822

commit: f4f6ff0

pi0 · 2025-12-01T10:45:09Z

src/types/config.ts

  database: DatabaseConnectionConfigs;
  devDatabase: DatabaseConnectionConfigs;
-  renderer?: { handler?: string; static?: boolean; template?: string };
+  renderer?: { handler?: string; static?: boolean; template?: string } | false;


Additional false value can be overridden in NitroConfig (input) interface to explicitly ask nitro do not (auto) detect renderer.template. This way we can keep other places as before

Updated 😉

kricsleo requested a review from pi0 as a code owner November 29, 2025 08:18

coderabbitai bot reviewed Nov 29, 2025

View reviewed changes

pi0 reviewed Dec 1, 2025

View reviewed changes

kricsleo added 2 commits December 1, 2025 22:02

chore: minimize changes

51c36b6

chore: lint

f4f6ff0

kricsleo force-pushed the feat/renderer-false branch from a5f4b2b to f4f6ff0 Compare December 1, 2025 14:04

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

feat(renderer): allow disabling renderer #3822

feat(renderer): allow disabling renderer #3822

Uh oh!

kricsleo commented Nov 29, 2025 •

edited

Loading

Uh oh!

vercel bot commented Nov 29, 2025

Uh oh!

coderabbitai bot commented Nov 29, 2025 •

edited

Loading

Walkthrough

Changes

Estimated code review effort

Uh oh!

coderabbitai bot left a comment

Uh oh!

pkg-pr-new bot commented Nov 29, 2025 •

edited

Loading

Uh oh!

pi0 Dec 1, 2025 •

edited

Loading

Uh oh!

kricsleo Dec 1, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

feat(renderer): allow disabling renderer #3822

Are you sure you want to change the base?

feat(renderer): allow disabling renderer #3822

Uh oh!

Conversation

kricsleo commented Nov 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🔗 Linked issue

❓ Type of change

📚 Description

📝 Checklist

Uh oh!

vercel bot commented Nov 29, 2025

Uh oh!

coderabbitai bot commented Nov 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Walkthrough

Changes

Estimated code review effort

Pre-merge checks and finishing touches

Uh oh!

coderabbitai bot left a comment

Choose a reason for hiding this comment

Uh oh!

pkg-pr-new bot commented Nov 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pi0 Dec 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kricsleo Dec 1, 2025

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

kricsleo commented Nov 29, 2025 •

edited

Loading

coderabbitai bot commented Nov 29, 2025 •

edited

Loading

pkg-pr-new bot commented Nov 29, 2025 •

edited

Loading

pi0 Dec 1, 2025 •

edited

Loading