SolidJS Devtools '/production' export #9564
Conversation
|
| Command | Status | Duration | Result |
|---|---|---|---|
nx affected --targets=test:sherif,test:knip,tes... |
❌ Failed | 1m 48s | View ↗ |
nx run-many --target=build --exclude=examples/*... |
✅ Succeeded | 1s | View ↗ |
☁️ Nx Cloud last updated this comment at 2025-08-18 18:10:13 UTC
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #9564 +/- ##
==========================================
- Coverage 45.14% 8.51% -36.64%
==========================================
Files 208 4 -204
Lines 8316 47 -8269
Branches 1878 11 -1867
==========================================
- Hits 3754 4 -3750
+ Misses 4115 35 -4080
+ Partials 447 8 -439 🚀 New features to boost your workflow:
|
that’s not true, we have documentation on how to lazy load devtools in production: https://tanstack.com/query/v5/docs/framework/react/devtools#devtools-in-production |
|
Ahh, I came from the SolidJS side which doesn't have a similar feature and assumed it was unimplemented. Sorry! Will update this PR to implement the |
WalkthroughExports in packages/solid-query-devtools/package.json were restructured to nested "." and "./production" entries, with updated build paths and an explicit "./package.json". A new src/production.tsx adds client-only dynamic wrappers for devtools components and re-exports a type. tsup.config.ts now builds two entries: index.tsx and production.tsx. Changes
Sequence Diagram(s)sequenceDiagram
participant Consumer
participant NodeResolver as Package Exports Resolver
participant Env as Runtime (SSR/Client)
participant Browser as ClientOnly Wrapper
participant Devtools as Devtools Modules
Consumer->>NodeResolver: import from "solid-query-devtools"
NodeResolver-->>Consumer: Resolve "." or "./production" export paths
alt Using "./production"
Consumer->>Env: Render <SolidQueryDevtools/...>
note over Env: SSR-safe placeholders
Env->>Browser: On client, mount component
Browser->>Devtools: dynamic import('./devtools' / './devtoolsPanel')
Devtools-->>Browser: Loaded component
Browser-->>Consumer: Render devtools
else Using "."
Consumer->>Env: Use base entry outputs
Env-->>Consumer: Load corresponding build/index/* files
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
Tip 🔌 Remote MCP (Model Context Protocol) integration is now available!Pro plan users can now connect to remote MCP servers from the Integrations page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats. ✨ Finishing Touches
🧪 Generate unit tests
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
packages/solid-query-devtools/src/index.tsx (2)
12-13: Expose the optional fallback prop in the public type (nice-to-have)clientOnly supports a fallback prop at runtime, but the exported type is typeof SolidQueryDevtoolsCompPanel (which doesn’t include fallback). Consider reflecting fallback in the type to improve DX.
You can adjust the typing like this (adds one import outside this hunk):
+import type { Component, JSX } from 'solid-js' +import type { DevtoolsPanelOptions } from './devtoolsPanel'Then change the export to:
-export const SolidQueryDevtoolsPanel: typeof SolidQueryDevtoolsCompPanel = - clientOnly(() => import('./devtoolsPanel')) +export const SolidQueryDevtoolsPanel: Component< + DevtoolsPanelOptions & { fallback?: JSX.Element } +> = clientOnly(() => import('./devtoolsPanel'))Alternatively, keep current typing but document that a fallback prop is accepted at runtime.
12-13: Plan the Solid “/production” entrypoint for parity with React docsGiven the discussion, please confirm a /production export for Solid mirrors React’s pattern (docs link in PR comments). If that’s part of this effort, ensure package.json exports and docs are updated accordingly so consumers have a documented path to include the panel in production.
Happy to draft the exports map and doc snippet for Solid’s /production entrypoint if you want.
packages/react-query-devtools/src/index.ts (1)
13-14: Call out potential behavior change for consumers rendering the Panel unconditionallyPreviously, ReactQueryDevtoolsPanel would no-op in production; now it will render. If any consumers relied on the old behavior, this is a visible change. Consider a changelog note and confirm the intended semver impact. Also ensure the docs clearly show how to include the Panel in production (and how to keep it out if desired).
I can propose a short changelog entry and doc update to the “Devtools in production” section covering the Panel specifically.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (2)
packages/react-query-devtools/src/index.ts(1 hunks)packages/solid-query-devtools/src/index.tsx(1 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (1)
packages/solid-query-devtools/src/index.tsx (2)
packages/solid-query-devtools/src/devtoolsPanel.tsx (1)
SolidQueryDevtoolsPanel(43-85)packages/solid-query-devtools/src/clientOnly.tsx (1)
clientOnly(17-43)
⏰ 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: Test
- GitHub Check: Preview
🔇 Additional comments (2)
packages/solid-query-devtools/src/index.tsx (1)
12-13: Un-gating SolidQueryDevtoolsPanel via clientOnly is SSR-safe and matches the PR goalAlways using clientOnly(() => import('./devtoolsPanel')) removes the dev-only guard while keeping SSR safety (server returns fallback). This lets consumers opt-in to include the panel in production, as intended.
packages/react-query-devtools/src/index.ts (1)
13-14: Directly exposing ReactQueryDevtoolsPanel is straightforward and aligns with the opt-in production usageRemoving the NODE_ENV guard for the Panel export enables intentional inclusion in production builds while keeping ReactQueryDevtools itself gated. This matches the intent of the PR.
oscartbeaumont
force-pushed
the
devtools-in-prod
branch
from
896ef1b to
d089b91
Compare
|
I will fix up the CodeRabbit comments and test failure in the morning! |
There was a problem hiding this comment.
Actionable comments posted: 2
🔭 Outside diff range comments (1)
packages/solid-query-devtools/tsup.config.ts (1)
23-25: Refactor tsup outDir to match nested export pathsThe override
tsup_option.outDir = 'build'flattens both entry outputs intobuild/, which conflicts with yourpackage.jsonexports (./build/index/...vs./build/production/...) and risks overwriting files. Update the config so each entry emits into its own subfolder:• File:
packages/solid-query-devtools/tsup.config.ts
• Lines: 23–25Apply this diff:
- tsup_options.forEach((tsup_option) => { - tsup_option.outDir = 'build' - }) + tsup_options.forEach((tsup_option, i) => { + const entry = preset_options.entries?.[i]?.entry + if (typeof entry === 'string') { + // derive "index" or "production" from "src/<name>.tsx" + const base = entry.split('/').pop()?.replace(/\.(t|j)sx?$/, '') + if (base) tsup_option.outDir = `build/${base}` + } + })This aligns outputs with your export map:
exports["."].*→./build/index/...exports["./production"].*→./build/production/...
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (3)
packages/solid-query-devtools/package.json(1 hunks)packages/solid-query-devtools/src/production.tsx(1 hunks)packages/solid-query-devtools/tsup.config.ts(1 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (1)
packages/solid-query-devtools/src/production.tsx (1)
packages/solid-query-devtools/src/clientOnly.tsx (1)
clientOnly(17-43)
⏰ 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: Preview
- GitHub Check: Test
🔇 Additional comments (4)
packages/solid-query-devtools/tsup.config.ts (1)
5-14: Good call adding a second entry for production wrappersAdding
src/production.tsxas its own entry aligns with the new./productionexport block and enables distinct build outputs. Keepingdev_entry: truefor both entries is consistent with thedevelopmentsub-exports.packages/solid-query-devtools/src/production.tsx (1)
12-12: Re-export of DevtoolsPanelOptions is correctKeeping the type re-export here ensures parity with the main entry and helps consumers avoid deep imports.
packages/solid-query-devtools/package.json (2)
40-58: Exports restructure for “.” looks consistent with multi-entry outputThe nested
build/index/...targets match the intent to separate artifacts by entry. This aligns with addingsrc/index.tsxas its own entry.
78-78: Explicit./package.jsonexport is a good additionThis improves compatibility with tooling that reads package metadata via the exports map.
| "./production": { | ||
| "@tanstack/custom-condition": "./src/production.tsx", | ||
| "solid": { | ||
| "development": "./build/production/dev.jsx", | ||
| "import": "./build/production/index.jsx" | ||
| }, | ||
| "development": { | ||
| "import": { | ||
| "types": "./build/production/index.d.ts", | ||
| "default": "./build/production/dev.js" | ||
| }, | ||
| "require": "./build/production/dev.cjs" | ||
| }, | ||
| "import": { | ||
| "types": "./build/production/index.d.ts", | ||
| "default": "./build/production/index.js" | ||
| }, | ||
| "require": "./build/production/index.cjs" | ||
| }, |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Production export block LGTM; ensure top-level fields are aligned and build outputs land in the nested folders
The ./production block mirrors the root export and points to build/production/... as expected. Combined with the current tsup config, ensure each entry emits into its own subdir (see tsup.config.ts comment).
Also, the top-level main, module, and types fields still point to ./build/index.* (without the extra directory level). With nested outputs, these should be updated to the new locations to avoid resolution breakage for tools that still read these fields.
[ suggest_essential_refactor ]
Apply these top-level updates (outside the changed hunk) to keep everything consistent:
{
"main": "./build/index/index.cjs",
"module": "./build/index/index.js",
"types": "./build/index/index.d.ts"
}And run this check to surface any discrepancies:
Expected: top-level main/module/types paths should correspond to the ./build/index/index.* files referenced under the . export.
🏁 Script executed:
#!/bin/bash
set -euo pipefail
cd packages/solid-query-devtools
echo "Top-level fields:"
jq -r '.main, .module, .types' package.json
echo
echo "Exports for root entry:"
jq -r '.exports["."].import.default, .exports["."].require, .exports["."].development.import.default, .exports["."].import.types' package.jsonLength of output: 502
Align top-level main/module/types with nested exports
The verification shows your root exports land in ./build/index/..., but the top-level fields still point to ./build/index.*. Update these to avoid resolution mismatches:
In packages/solid-query-devtools/package.json, change:
--- package.json
@@ Lines 59-77
- "main": "./build/index.cjs",
- "module": "./build/index.js",
- "types": "./build/index.d.ts",
+ "main": "./build/index/index.cjs",
+ "module": "./build/index/index.js",
+ "types": "./build/index/index.d.ts"After applying, re-run the jq check to confirm:
cd packages/solid-query-devtools
jq -r '.main, .module, .types, .exports["."].import.default, .exports["."].require, .exports["."].development.import.default, .exports["."].import.types' package.jsonExpected output paths should all reference ./build/index/index.*.
🤖 Prompt for AI Agents
In packages/solid-query-devtools/package.json around lines 59 to 77, the
package's nested exports point to files under ./build/index/... but the
top-level "main", "module", and "types" fields (and several nested export paths)
still reference the old ./build/production/* locations; update the top-level
fields "main", "module", and "types" to ./build/index/index.cjs,
./build/index/index.js, and ./build/index/index.d.ts respectively, and change
the export entries (.exports["."].import.default, .exports["."].require,
.exports["."].development.import.default, .exports["."].import.types) to
reference ./build/index/index.* so all paths consistently use
./build/index/index.*, then re-run the provided jq command to verify the outputs
point to ./build/index/index.* as expected.
| import type SolidQueryDevtoolsComp from './devtools' | ||
| import type SolidQueryDevtoolsCompPanel from './devtoolsPanel' |
There was a problem hiding this comment.
Type-only default imports with typeof cause a TS error; annotate with the default export type instead
import type SolidQueryDevtoolsComp from './devtools' creates a type-only symbol. Using typeof SolidQueryDevtoolsComp then refers to a value that does not exist at runtime, which is a TypeScript error. The same applies to devtoolsPanel.
Annotate the exports with the default export’s type directly, and adjust the imports accordingly.
Apply this diff:
-import type SolidQueryDevtoolsComp from './devtools'
-import type SolidQueryDevtoolsCompPanel from './devtoolsPanel'
+import type { default as SolidQueryDevtoolsComp } from './devtools'
+import type { default as SolidQueryDevtoolsCompPanel } from './devtoolsPanel'
-export const SolidQueryDevtools: typeof SolidQueryDevtoolsComp = clientOnly(
+export const SolidQueryDevtools: SolidQueryDevtoolsComp = clientOnly(
() => import('./devtools'),
)
-export const SolidQueryDevtoolsPanel: typeof SolidQueryDevtoolsCompPanel =
- clientOnly(() => import('./devtoolsPanel'))
+export const SolidQueryDevtoolsPanel: SolidQueryDevtoolsCompPanel = clientOnly(
+ () => import('./devtoolsPanel'),
+)Also applies to: 5-10
🤖 Prompt for AI Agents
In packages/solid-query-devtools/src/production.tsx lines 2–3 (and similarly
lines 5–10), the code uses type-only default imports and then refers to typeof
on those names which fails at runtime; replace the type-only default imports
with a type import that references the module's default export type (e.g.,
import type { default as X } from './module') and annotate the exported values
with that imported type instead of using typeof, updating both devtools and
devtoolsPanel imports/exports accordingly.
Align the SolidJS Query Devtools package with the React one by including the '/production' export which allows bundling TanStack Query Devtools in production builds.
Summary by CodeRabbit
New Features
Chores