• pnpm-lock.yaml: Language not supported

packages/template/src/dev-tool/iframe-tab.tsx (1)

73-80: onError is unreliable for detecting iframe load failures.

Many iframe loading failures (CSP blocks, X-Frame-Options denials, network issues) don't fire onError. The iframe may display blank content without triggering the error state. Consider adding a timeout fallback or documenting this limitation.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/template/src/dev-tool/iframe-tab.tsx` around lines 73 - 80, The
iframe's onError is unreliable; add a timeout fallback that starts whenever src
changes (store an iframe ref like iframeRef) and clears on handleLoad and
handleError; if the timeout elapses (e.g., 5–10s) check the iframeRef.current
(try accessing contentDocument/contentWindow safely) and if it's empty or
cross-origin-inaccessible treat it as a load failure and set the same error
state used by handleError/loading, and also document this limitation in comments
next to the iframe, referencing the iframe element, handleLoad, handleError,
loading, src and title so future readers know why the timer exists.

examples/docs-examples/src/app/team/[teamId]/page.tsx (1)

16-21: Use encodeURIComponent() for URL path segment.

The defensive null check is appropriate given the underlying type-safety gap in TeamSwitcher. However, the URL construction should use proper encoding for consistency with coding guidelines.

♻️ Suggested fix

         urlMap={(t) => {
           if (t == null) {
             throw new Error("SelectedTeamSwitcher urlMap expected a non-null team");
           }
-          return `/team/${t.id}`;
+          return `/team/${encodeURIComponent(t.id)}`;
         }}

As per coding guidelines: "Use urlString`` or encodeURIComponent()` instead of normal string interpolation for URLs for consistency."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@examples/docs-examples/src/app/team/`[teamId]/page.tsx around lines 16 - 21,
The urlMap function constructs a raw path using string interpolation; update url
creation in the urlMap arrow function to encode the team id (use
encodeURIComponent(t.id) or the project's urlString helper) while keeping the
existing null-check that throws if t is null—change the return for urlMap to
produce an encoded path like /team/<encoded-id> so ids with unsafe characters
are properly escaped.

docs/src/components/stack-auth/stack-team-switcher.tsx (1)

235-235: Code example doesn't match actual implementation.

The generateCodeExample() at line 125 shows (team: { id: string }) => ... without null handling, but the actual implementation here accepts { id: string } | null. Users copying the code example won't get the defensive null check.

Additionally, consider using encodeURIComponent(team.id) for URL consistency.

♻️ Suggested fixes

1. Update the code example generator (around line 125) to match:

     if (props.urlMap) {
-      propsArray.push('urlMap={(team: { id: string }) => `/teams/${team.id}/dashboard`}');
+      propsArray.push('urlMap={(team: { id: string } | null) => team ? `/teams/${team.id}/dashboard` : `/`}');
     }

2. Encode the URL path:

-                urlMap={props.urlMap ? (team: { id: string } | null) => team ? `/teams/${team.id}/dashboard` : '/' : undefined}
+                urlMap={props.urlMap ? (team: { id: string } | null) => team ? `/teams/${encodeURIComponent(team.id)}/dashboard` : '/' : undefined}

As per coding guidelines: "Use urlString`` or encodeURIComponent()` instead of normal string interpolation for URLs."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/src/components/stack-auth/stack-team-switcher.tsx` at line 235, The code
example produced by generateCodeExample() must match the actual urlMap prop
signature used in stack-team-switcher.tsx: update generateCodeExample() to show
the parameter as (team: { id: string } | null) => team ?
`/teams/${encodeURIComponent(team.id)}/dashboard` : '/' (or equivalent using
urlString/encodeURIComponent) so the example includes the null defensive check
and encodes team.id; search for generateCodeExample and the urlMap prop to apply
the change and replace plain string interpolation of team.id with
encodeURIComponent(team.id) (or the project urlString helper) for URL safety.

packages/template/src/dev-tool/dev-tool-indicator.tsx (1)

65-70: Use a monotonic clock for duration.

These timings are currently derived from Date.now(), so a system clock adjustment can make the dev-tool latency jump or even go negative. Keep the wall-clock timestamp, but measure elapsed time with performance.now().

As per coding guidelines, don't use Date.now() for measuring elapsed (real) time, instead use performance.now().

Also applies to: 111-117

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/template/src/dev-tool/dev-tool-indicator.tsx` around lines 65 - 70,
The code currently uses Date.now() (startTime) to compute request duration in
the fetch wrapper (around the fetch call that uses originalFetch), which is
susceptible to system clock changes; change it to record a monotonic start via
performance.now() (e.g., startMonotonic = performance.now()) and compute
duration as performance.now() - startMonotonic while keeping the wall-clock
timestamp from Date.now() if you still need a timestamp; update the other
analogous occurrence that computes elapsed time elsewhere in this file (the
second startTime/duration pair) the same way to use performance.now() for
elapsed measurements.

packages/template/src/dev-tool/component-catalog.tsx (1)

31-33: Explain the any escape hatch here or narrow it.

CatalogEntry is exported, so React.ComponentType<any> becomes the registry contract for every previewed component. If heterogeneous props make any unavoidable, please add the required inline note about why it's safe and where prop misuse is still caught.

As per coding guidelines, try to avoid the any type; whenever you need it, leave a comment explaining why you're using it and how you can be certain that errors would still be flagged.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/template/src/dev-tool/component-catalog.tsx` around lines 31 - 33,
The exported type CatalogEntry currently uses React.ComponentType<any>, which
leaks an any into the public registry contract; either make CatalogEntry generic
(e.g., CatalogEntry<P = unknown> with component: React.ComponentType<P>) or
switch to React.ComponentType<unknown> to avoid any, and update callers to
provide the concrete prop type, or if heterogeneous props truly make any
unavoidable add a concise inline comment on the CatalogEntry.type explaining why
any is required, where runtime/compile-time prop validation still occurs (e.g.,
preview wrappers or story files), and add a TODO to tighten the type when
components share a common prop shape; refer to the exported symbol CatalogEntry
and its component field when making the change.

packages/template/src/dev-tool/tabs/overview-tab.tsx (2)

131-131: Prefer explicit null check over non-null assertion.

Per coding guidelines, prefer ?? throwErr(...) over non-null assertions. Although user is checked in the JSX conditional, the async function scope doesn't carry that narrowing.

Suggested fix

-      await user!.signOut();
+      if (user == null) {
+        throw new Error('Cannot sign out: no user is signed in');
+      }
+      await user.signOut();

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/template/src/dev-tool/tabs/overview-tab.tsx` at line 131, The
non-null assertion on user in the async call await user!.signOut() should be
replaced with an explicit null-check that throws if user is missing; update the
sign-out call in the same scope (the function that calls user.signOut) to use
the null-coalescing pattern (user ?? throwErr("user is undefined when attempting
signOut")) before invoking signOut, or otherwise guard with an if and throw so
the function no longer relies on the non-null assertion operator.

---

89-91: Avoid catch (e: any) pattern.

The coding guidelines prohibit using any. For error handling, consider using a type guard or utility to safely extract the error message.

Suggested approach

-    } catch (e: any) {
-      setStatus({ type: 'error', message: e.message || 'Unknown error' });
+    } catch (e) {
+      setStatus({ type: 'error', message: e instanceof Error ? e.message : 'Unknown error' });
     }

Apply the same pattern to the other catch blocks at lines 121-123 and 133-135.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/template/src/dev-tool/tabs/overview-tab.tsx` around lines 89 - 91,
Replace the unsafe "catch (e: any)" usages with "catch (err: unknown)" and use a
small type-guard/helper to extract a safe message before calling setStatus; for
example, add a getErrorMessage(err: unknown): string utility that checks for err
being an Error or having a message property and returns a string, then change
the three catch blocks that call setStatus to use getErrorMessage(err) when
creating the status ({ type: 'error', message: getErrorMessage(err) }); update
all occurrences (the catch currently using setStatus at the top and the two
other similar catch blocks) to use this helper.

packages/template/src/dev-tool/dev-tool-context.tsx (2)

130-132: Document the any cast on globalThis.

The coding guidelines require comments explaining any usage. This global attachment is for cross-module interop with the fetch interceptor.

Suggested fix

 // Expose globally so the fetch interceptor (which may be installed once) can
 // always reach the latest store even after HMR / remounts.
 if (typeof globalThis !== 'undefined') {
+  // Using `any` because globalThis doesn't have a typed slot for our store.
+  // This is safe as we control both the writer (here) and readers (dev-tool-indicator.tsx).
   (globalThis as any).__STACK_DEV_TOOL_LOG_STORE__ = globalLogStore;
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/template/src/dev-tool/dev-tool-context.tsx` around lines 130 - 132,
Add a short inline comment explaining the use of "any" on globalThis when
assigning __STACK_DEV_TOOL_LOG_STORE__ to globalLogStore: state that the cast is
intentional to attach a cross-module global used for the fetch
interceptor/cross-module interop, and that TypeScript typing is intentionally
bypassed here because globalThis has no typed property for this runtime-only
debugging store; keep the comment adjacent to the cast that sets (globalThis as
any).__STACK_DEV_TOOL_LOG_STORE__ = globalLogStore and mention the related
symbol names (__STACK_DEV_TOOL_LOG_STORE__, globalLogStore, fetch interceptor)
so future readers know why the any is necessary.

---

72-74: Add comment explaining why errors are silently ignored.

Per coding guidelines, errors shouldn't be silently swallowed. For localStorage operations, silent failure is often acceptable (quota exceeded, private browsing, etc.), but the reasoning should be documented.

Suggested fix

   } catch {
-    // ignore
+    // localStorage may be unavailable (private browsing, quota exceeded, etc.)
+    // Failing silently is acceptable here as state persistence is non-critical
   }

Apply the same to the catch block at lines 83-85.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/template/src/dev-tool/dev-tool-context.tsx` around lines 72 - 74,
The empty catch blocks in dev-tool-context (around the localStorage access in
the code surrounding the anonymous catch { // ignore }) silently swallow errors;
update both catch blocks (the one shown and the similar one later) to include a
brief comment explaining why errors are intentionally ignored (e.g.,
localStorage may be unavailable in private mode or exceed quota, so failures are
non-fatal for dev UX) and keep no-op behavior; ensure the comment references the
localStorage/read or write operation performed (so future maintainers know the
rationale) and leave behavior unchanged.

packages/template/src/dev-tool/tabs/console-tab.tsx (1)

161-162: Avoid any in map callback.

The any type in (p: any) => p.id can be replaced with a more specific type or type assertion that documents the expected shape.

Suggested fix

     if (key === 'oauthProviders' && Array.isArray(value)) {
-      lines.push(`${key}: ${value.map((p: any) => p.id).join(', ') || 'None'}`);
+      lines.push(`${key}: ${value.map((p: { id: string }) => p.id).join(', ') || 'None'}`);
     } else {

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/template/src/dev-tool/tabs/console-tab.tsx` around lines 161 - 162,
The map callback uses an unsafe any: replace (p: any) => p.id with a typed shape
or assertion for the expected provider object (e.g., define or use an
OAuthProvider type/interface with an id property and cast value to
OAuthProvider[] before mapping, or change the callback to (p: OAuthProvider) =>
p.id) so the compiler knows the structure when mapping in the oauthProviders
branch (the check key === 'oauthProviders' and the value.map call should use the
new typed shape).