Stephansama/ste 179 use tsnapi to create api snapshots#272
Conversation
🦋 Changeset detectedLatest commit: 997dd5d The changes in this PR will be included in the next version bump. This PR includes changesets to release 16 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Warning Rate limit exceeded
You’ve run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (34)
📝 WalkthroughWalkthroughThis PR integrates the ChangesIntegrate tsnapi for API Snapshot Generation & Migrate to ESM-Only
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Poem
✨ Finishing Touches🧪 Generate unit tests (beta)
|
Codecov Report❌ Patch coverage is 📢 Thoughts on this report? Let us know! |
There was a problem hiding this comment.
Code Review
This pull request integrates tsnapi across several packages to generate public API snapshots during the build process. The changes involve updating workspace configurations, adding the ApiSnapshot plugin to package build configs, and committing the initial set of generated snapshots. Feedback highlights potential bugs in the snapshot generation tool, specifically stray characters and discrepancies between type definitions and implementation files in ai-commit-msg and multipublish. Additionally, a request was made to include missing snapshots for the catppuccin-jsonresume-theme package to maintain consistency.
| /* no exports */ions | ||
| export async function run() {} | ||
| // #endregion No newline at end of file |
There was a problem hiding this comment.
This generated snapshot appears to have a couple of issues:
- There's an unexpected
ionsstring on line 4, which seems to be a generation artifact. - This file exports a
runfunction, but the corresponding type definition snapshot (index.snapshot.d.ts) indicates there are no exports.
This discrepancy and artifact suggest a potential issue in the tsnapi generation process for this package. Please investigate and fix the snapshot generation to ensure the API surface is correctly and cleanly represented.
| /* no exports */ions | ||
| export async function run() {} | ||
| // #endregion No newline at end of file |
There was a problem hiding this comment.
Similar to another snapshot file in this PR, this generated file appears to have some issues:
- A stray
ionsstring is present on line 4. - This file exports a
runfunction, while its corresponding type definition snapshot (index.snapshot.d.ts) states there are no exports.
This indicates a recurring issue with the snapshot generation. It's important to have correct and clean API snapshots. Could you please look into the tsnapi configuration or the tool itself to resolve this?
| entry: ["src/index.ts"], | ||
| exports: true, | ||
| format: ["esm", "cjs"], | ||
| plugins: [ApiSnapshot()], |
There was a problem hiding this comment.
The ApiSnapshot plugin is enabled for this package, but there are no generated snapshot files in this pull request. Other packages, even those without any exports, have corresponding snapshot files. Was this an oversight, or is there a reason no snapshot is generated for this package? For consistency, it would be beneficial to have snapshots for all packages where this plugin is enabled.
There was a problem hiding this comment.
Actionable comments posted: 8
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@core/ai-commit-msg/__snapshots__/tsnapi/index.snapshot.js`:
- Around line 4-6: Remove the stray token "ions" from the snapshot comment so
the module can evaluate; specifically edit the snapshot string that currently
reads "/* no exports */ions" and change it back to a valid comment like "/* no
exports */" (affecting the snapshot that contains "export async function run()
{}") then regenerate the snapshot to ensure the file no longer contains the
hanging identifier.
In `@core/ai-commit-msg/tsdown.config.ts`:
- Line 13: The schema config entry currently lacks the ApiSnapshot() plugin
while the index.ts entry includes it; update the second tsdown config entry (the
one targeting schema.ts and its custom export './schema.json') to include
ApiSnapshot() in its plugins array so API snapshots are generated for the schema
surface as well, i.e., add ApiSnapshot() to the plugins list for the schema
config entry.
In `@core/multipublish/__snapshots__/tsnapi/index.snapshot.js`:
- Around line 4-6: The snapshot JS contains a stray token "ions" and an
unexpected export "export async function run() {}" that contradicts the
accompanying d.ts which states "/* no exports */"; regenerate the multipublish
tsnapi snapshots so the JS and d.ts are consistent and the stray "ions" token is
removed — specifically fix the artifact in index.snapshot.js by removing the
stray token and removing or aligning the exported symbol "run" with
index.snapshot.d.ts (or update the d.ts if the export should exist), then re-run
snapshot generation to produce harmonized index.snapshot.js and
index.snapshot.d.ts.
In `@core/typed-events/__snapshots__/tsnapi/errors.snapshot.d.ts`:
- Around line 5-16: The errors export path currently only exports the four error
classes (TypedBroadcastChannelError, TypedBroadcastEventError, TypedEventError,
TypedMessageError) but not their base ValidatorError or the StandardSchemaV1
symbol; update core/typed-events/src/errors.ts to also export ValidatorError
from core/typed-events/src/utils/index.ts and re-export StandardSchemaV1 (or its
module) so consumers importing from `@stephansama/typed-events/errors` get
ValidatorError and StandardSchemaV1 alongside the four error classes.
In `@core/typed-events/__snapshots__/tsnapi/errors.snapshot.js`:
- Around line 5-16: The snapshot is invalid because ValidatorError isn't
imported and the constructor parameter names are duplicated; add an import for
ValidatorError from the original module (core/typed-events/src/utils/error.ts),
update each snapshot class (TypedBroadcastChannelError,
TypedBroadcastEventError, TypedEventError, TypedMessageError) to mirror the real
constructors (use distinct parameter names or the same typed params as the
source, e.g., scope and issues) and then regenerate the snapshot so the exported
classes match the source definitions.
In `@core/typed-events/__snapshots__/tsnapi/index.snapshot.d.ts`:
- Line 87: The file re-exports StandardSchemaV1 but never imports it, causing a
TypeScript error; fix by adding an import statement for StandardSchemaV1 (the
same exported symbol used throughout the file and re-exported at the end) from
its defining module before the export, so the final line export {
StandardSchemaV1 } references a valid imported binding.
In `@pnpm-workspace.yaml`:
- Line 214: The addition of unrs-resolver to ignoredBuiltDependencies is
unclear; update the PR by either removing unrs-resolver if unrelated to tsnapi
or add a short justification comment and changelog note stating it was added to
avoid native build failures from ESLint tooling (e.g., eslint-import-context /
eslint-import-resolver-typescript) during workspace installs; reference the pnpm
setting ignoredBuiltDependencies and the package name unrs-resolver in your
change so reviewers can see whether this is a tooling workaround or intended for
tsnapi integration.
- Line 194: Change the tsnapi dependency's loose caret range to a stricter spec:
replace the caret range `^0.3.2` for package tsnapi with either a tilde `~0.3.2`
to allow only patch updates or pin to an exact version `0.3.2` to fully lock the
dependency; update the entry for tsnapi in the workspace dependencies
accordingly and run a quick install to verify lockfile changes.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: e230bd4c-71a0-430a-9a01-7ad36718e336
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (43)
core/ai-commit-msg/__snapshots__/tsnapi/index.snapshot.d.tscore/ai-commit-msg/__snapshots__/tsnapi/index.snapshot.jscore/ai-commit-msg/tsdown.config.tscore/astro-iconify-svgmap/__snapshots__/tsnapi/cli.snapshot.d.tscore/astro-iconify-svgmap/__snapshots__/tsnapi/cli.snapshot.jscore/astro-iconify-svgmap/__snapshots__/tsnapi/get.snapshot.d.tscore/astro-iconify-svgmap/__snapshots__/tsnapi/get.snapshot.jscore/astro-iconify-svgmap/__snapshots__/tsnapi/index.snapshot.d.tscore/astro-iconify-svgmap/__snapshots__/tsnapi/index.snapshot.jscore/astro-iconify-svgmap/tsdown.config.tscore/auto-readme/__snapshots__/tsnapi/index.snapshot.d.tscore/auto-readme/__snapshots__/tsnapi/index.snapshot.jscore/auto-readme/tsdown.config.tscore/catppuccin-jsonresume-theme/tsdown.config.tscore/eslint-config/__snapshots__/tsnapi/index.snapshot.d.tscore/eslint-config/__snapshots__/tsnapi/index.snapshot.jscore/eslint-config/package.jsoncore/eslint-config/tsdown.config.tscore/multipublish/__snapshots__/tsnapi/index.snapshot.d.tscore/multipublish/__snapshots__/tsnapi/index.snapshot.jscore/multipublish/tsdown.config.tscore/typed-env/__snapshots__/tsnapi/index.snapshot.d.tscore/typed-env/__snapshots__/tsnapi/index.snapshot.jscore/typed-env/tsdown.config.tscore/typed-events/__snapshots__/tsnapi/errors.snapshot.d.tscore/typed-events/__snapshots__/tsnapi/errors.snapshot.jscore/typed-events/__snapshots__/tsnapi/index.snapshot.d.tscore/typed-events/__snapshots__/tsnapi/index.snapshot.jscore/typed-events/__snapshots__/tsnapi/react.snapshot.d.tscore/typed-events/__snapshots__/tsnapi/react.snapshot.jscore/typed-events/tsdown.config.tscore/typed-nocodb-api/__snapshots__/tsnapi/index.snapshot.d.tscore/typed-nocodb-api/__snapshots__/tsnapi/index.snapshot.jscore/typed-nocodb-api/tsdown.config.tscore/typed-templates/__snapshots__/tsnapi/index.snapshot.d.tscore/typed-templates/__snapshots__/tsnapi/index.snapshot.jscore/typed-templates/tsdown.config.tscore/types-lhci/__snapshots__/tsnapi/index.snapshot.d.tscore/types-lhci/__snapshots__/tsnapi/index.snapshot.jscore/types-lhci/tsdown.config.tseslint.config.tspackage.jsonpnpm-workspace.yaml
| export declare class TypedBroadcastChannelError extends ValidatorError { | ||
| constructor(_: string, _: readonly StandardSchemaV1.Issue[]); | ||
| } | ||
| export declare class TypedBroadcastEventError extends ValidatorError { | ||
| constructor(_: string, _: readonly StandardSchemaV1.Issue[]); | ||
| } | ||
| export declare class TypedEventError extends ValidatorError { | ||
| constructor(_: string, _: readonly StandardSchemaV1.Issue[]); | ||
| } | ||
| export declare class TypedMessageError extends ValidatorError { | ||
| constructor(_: string, _: readonly StandardSchemaV1.Issue[]); | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Find ValidatorError definition in the typed-events package
ast-grep --pattern 'class ValidatorError $$$'
# Alternative: search for ValidatorError export
rg -t ts "export.*class ValidatorError" core/typed-events/Repository: stephansama/packages
Length of output: 145
🏁 Script executed:
cat -n core/typed-events/__snapshots__/tsnapi/errors.snapshot.d.ts | head -30Repository: stephansama/packages
Length of output: 840
🏁 Script executed:
# Find the source file that might generate this snapshot
find core/typed-events -name "*.ts" -not -path "*/node_modules/*" -not -path "*/__snapshots__/*" | xargs rg -l "TypedBroadcastChannelError|TypedBroadcastEventError|TypedEventError|TypedMessageError" | head -10Repository: stephansama/packages
Length of output: 236
🏁 Script executed:
# Check if StandardSchemaV1 is imported or defined anywhere in the typed-events package
rg -t ts "StandardSchemaV1" core/typed-events/src/ --max-count 20Repository: stephansama/packages
Length of output: 3866
🏁 Script executed:
cat -n core/typed-events/src/errors.tsRepository: stephansama/packages
Length of output: 302
🏁 Script executed:
# Also check what tsnapi configuration or export pattern exists
find core/typed-events -name "tsconfig.json" -o -name "tsnapi.config.*" | head -5Repository: stephansama/packages
Length of output: 96
🏁 Script executed:
# Check if ValidatorError is exported from the main index file
fd -t f "index.ts" core/typed-events/src/ -exec cat -n {} \;Repository: stephansama/packages
Length of output: 295
🏁 Script executed:
# Check the main package.json to see what the exports point to
cat -n core/typed-events/package.json | grep -A 10 '"exports"'Repository: stephansama/packages
Length of output: 398
🏁 Script executed:
# Verify what the snapshot file is testing - check if there's an errors export in package.json exports
cat -n core/typed-events/package.jsonRepository: stephansama/packages
Length of output: 2638
🏁 Script executed:
# Check if ValidatorError is exported from the main index.ts file
cat core/typed-events/src/index.tsRepository: stephansama/packages
Length of output: 336
🏁 Script executed:
# Check what the actual compiled/exported types include - look at how ValidatorError is made available
rg -t ts "export.*ValidatorError" core/typed-events/src/ -A 2Repository: stephansama/packages
Length of output: 1909
🏁 Script executed:
# Search for tsnapi configuration
find core/typed-events -type f -name "*tsnapi*" -o -name "*.config.*" | xargs ls -la 2>/dev/null | head -20Repository: stephansama/packages
Length of output: 230
🏁 Script executed:
# Check utils/index.ts to confirm what's exported
cat core/typed-events/src/utils/index.tsRepository: stephansama/packages
Length of output: 200
🏁 Script executed:
# Verify if ValidatorError should be in the public API
rg -t ts "ValidatorError" core/typed-events/src/ --max-count 30 | grep -E "(export|import)" | head -20Repository: stephansama/packages
Length of output: 1182
🏁 Script executed:
# Check what the `@/utils` export includes by looking at the utils barrel export chain
cat core/typed-events/src/utils/types.ts | head -50Repository: stephansama/packages
Length of output: 1394
🏁 Script executed:
# Check if there are other snapshot files to see the pattern for imports
find core/typed-events/__snapshots__ -type f -name "*.snapshot.d.ts" | head -3 | xargs head -20Repository: stephansama/packages
Length of output: 3032
The snapshot file is auto-generated and accurately reflects the public API. The issue is in the source code, not the snapshot.
The ./errors export path (defined in core/typed-events/src/errors.ts) only exports the four error classes but does not export ValidatorError (which lives in core/typed-events/src/utils/index.ts) or re-export StandardSchemaV1. Consumers importing from @stephansama/typed-events/errors would receive error classes that extend a base class not available in that export path. Update core/typed-events/src/errors.ts to export ValidatorError and optionally StandardSchemaV1 so the error classes can be properly used by consumers.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@core/typed-events/__snapshots__/tsnapi/errors.snapshot.d.ts` around lines 5 -
16, The errors export path currently only exports the four error classes
(TypedBroadcastChannelError, TypedBroadcastEventError, TypedEventError,
TypedMessageError) but not their base ValidatorError or the StandardSchemaV1
symbol; update core/typed-events/src/errors.ts to also export ValidatorError
from core/typed-events/src/utils/index.ts and re-export StandardSchemaV1 (or its
module) so consumers importing from `@stephansama/typed-events/errors` get
ValidatorError and StandardSchemaV1 alongside the four error classes.
| export class TypedBroadcastChannelError extends ValidatorError { | ||
| constructor(_, _) {} | ||
| } | ||
| export class TypedBroadcastEventError extends ValidatorError { | ||
| constructor(_, _) {} | ||
| } | ||
| export class TypedEventError extends ValidatorError { | ||
| constructor(_, _) {} | ||
| } | ||
| export class TypedMessageError extends ValidatorError { | ||
| constructor(_, _) {} | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Find where ValidatorError is exported
rg -t ts -t js "export.*ValidatorError" core/typed-events/src/
# Check if there's a base errors module
fd -e ts -e js 'error' core/typed-events/src/
# Try to parse the snapshot to see if it's syntactically valid
node -e "import('./core/typed-events/__snapshots__/tsnapi/errors.snapshot.js').catch(e => console.log('Error:', e.message))"Repository: stephansama/packages
Length of output: 823
🏁 Script executed:
cat -n core/typed-events/__snapshots__/tsnapi/errors.snapshot.jsRepository: stephansama/packages
Length of output: 644
🏁 Script executed:
# Check the actual source file definitions
cat -n core/typed-events/src/errors.ts
# Check the source error classes
head -30 core/typed-events/src/message.ts
head -30 core/typed-events/src/event.tsRepository: stephansama/packages
Length of output: 1960
🏁 Script executed:
# Check if ValidatorError import is at the top of the snapshot file
head -20 core/typed-events/__snapshots__/tsnapi/errors.snapshot.jsRepository: stephansama/packages
Length of output: 525
Fix missing import and syntax error in auto-generated snapshot.
This auto-generated snapshot file cannot be loaded due to two issues:
- Missing import:
ValidatorErroris not imported. It's defined incore/typed-events/src/utils/error.ts. - Invalid syntax: Constructors have duplicate parameter names
constructor(_, _) {}, which is invalid JavaScript. The source files have proper typed parameters likeconstructor(scope: string, issues: readonly StandardSchemaV1.Issue[]).
Add the missing import and ensure the snapshot is correctly regenerated to match the source class definitions.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@core/typed-events/__snapshots__/tsnapi/errors.snapshot.js` around lines 5 -
16, The snapshot is invalid because ValidatorError isn't imported and the
constructor parameter names are duplicated; add an import for ValidatorError
from the original module (core/typed-events/src/utils/error.ts), update each
snapshot class (TypedBroadcastChannelError, TypedBroadcastEventError,
TypedEventError, TypedMessageError) to mirror the real constructors (use
distinct parameter names or the same typed params as the source, e.g., scope and
issues) and then regenerate the snapshot so the exported classes match the
source definitions.
| // #endregion | ||
|
|
||
| // #region Other | ||
| export { StandardSchemaV1 } |
There was a problem hiding this comment.
Re-exporting StandardSchemaV1 without importing it.
Line 87 attempts to re-export StandardSchemaV1, but this symbol is never imported in the file, which will cause a TypeScript error. The file uses StandardSchemaV1 throughout (lines 5, 8, 12, 15, 18, 24, etc.), so it should be imported before being re-exported.
🔧 Suggested fix
/**
* Generated by tsnapi — public API snapshot of `@stephansama/typed-events`
*/
+import type { StandardSchemaV1 } from '@standard-schema/spec';
+
// `#region` Interfaces🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@core/typed-events/__snapshots__/tsnapi/index.snapshot.d.ts` at line 87, The
file re-exports StandardSchemaV1 but never imports it, causing a TypeScript
error; fix by adding an import statement for StandardSchemaV1 (the same exported
symbol used throughout the file and re-exported at the end) from its defining
module before the export, so the final line export { StandardSchemaV1 }
references a valid imported binding.
| - core-js-pure | ||
| - highlight.js | ||
| - sharp | ||
| - unrs-resolver |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Check if unrs-resolver is related to tsnapi
# Check tsnapi dependencies
curl -s https://registry.npmjs.org/tsnapi/0.3.2 | jq -r '.dependencies, .peerDependencies, .optionalDependencies'
# Search for unrs-resolver references in the codebase
rg -l 'unrs-resolver' --type yaml --type jsonRepository: stephansama/packages
Length of output: 266
🏁 Script executed:
cat pnpm-workspace.yaml | head -n 230 | tail -n 30Repository: stephansama/packages
Length of output: 696
🏁 Script executed:
rg 'unrs-resolver' -B 5 -A 5Repository: stephansama/packages
Length of output: 4480
🏁 Script executed:
fd package.json -x grep -l 'unrs-resolver' {}Repository: stephansama/packages
Length of output: 46
Clarify the purpose of adding unrs-resolver to ignoredBuiltDependencies.
unrs-resolver is not a dependency of tsnapi and appears unrelated to the tsnapi integration. It is a native build dependency used by ESLint-related packages (eslint-import-context, eslint-import-resolver-typescript) in the monorepo. Confirm whether this was added as part of an ESLint or tooling update, or provide context for why it's needed.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@pnpm-workspace.yaml` at line 214, The addition of unrs-resolver to
ignoredBuiltDependencies is unclear; update the PR by either removing
unrs-resolver if unrelated to tsnapi or add a short justification comment and
changelog note stating it was added to avoid native build failures from ESLint
tooling (e.g., eslint-import-context / eslint-import-resolver-typescript) during
workspace installs; reference the pnpm setting ignoredBuiltDependencies and the
package name unrs-resolver in your change so reviewers can see whether this is a
tooling workaround or intended for tsnapi integration.
There was a problem hiding this comment.
Actionable comments posted: 19
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
core/astro-iconify-svgmap/package.json (1)
42-42:⚠️ Potential issue | 🟠 Major | ⚡ Quick winChange build script to align with ESM-only configuration.
The
buildscript uses--profile=node16which contradicts the package's ESM-only setup:tsdown.config.tssetsattw: { profile: "esm-only" }, all exports are.mjsfiles, andformatis["esm"]. Since CLI flags override config, the build runs attw checks under thenode16(dual ESM/CJS) profile against an ESM-only export map, risking false positives or masking real issues. TheprepublishOnlyscript correctly omits the flag.Suggested fix
- "build": "tsdown --profile=node16", + "build": "tsdown",(Let
tsdown.config.tsbe the source of truth)🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@core/astro-iconify-svgmap/package.json` at line 42, The build script currently forces tsdown to run with --profile=node16 which conflicts with the project's ESM-only configuration in tsdown.config.ts (attw.profile = "esm-only"); update the "build" script (the package.json "build" entry that invokes tsdown) to stop passing --profile=node16 so tsdown uses the tsdown.config.ts settings (or explicitly use --profile=esm-only if you prefer an explicit flag), ensuring attw runs against the ESM-only exports consistent with prepublishOnly.
♻️ Duplicate comments (1)
core/multipublish/__snapshots__/tsnapi/index.snapshot.js (1)
1-6:⚠️ Potential issue | 🟠 Major | ⚡ Quick winExport contract mismatch between JS and TypeScript declaration snapshots.
The past review comment about the stray
ionstoken appears resolved, but the export mismatch persists: this snapshot exportsasync function run()while the companionindex.snapshot.d.tsdeclares/* no exports */.Regenerate the tsnapi snapshots to ensure the
.jsand.d.tsfiles declare a consistent public API contract.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@core/multipublish/__snapshots__/tsnapi/index.snapshot.js` around lines 1 - 6, The JS and TypeScript tsnapi snapshots disagree: index.snapshot.js exports "async function run()" but index.snapshot.d.ts declares no exports; regenerate the tsnapi snapshots so the public API contract is consistent (either include run in the .d.ts or remove the run export from the JS snapshot), e.g., run the project's tsnapi snapshot/regen command or the tsnapi CLI to rebuild index.snapshot.js and index.snapshot.d.ts, verify the export for run is present or absent in both, and commit the updated snapshots.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@core/ai-commit-msg/__snapshots__/tsnapi/schema.snapshot.d.ts`:
- Line 35: The models constant exported as models in
core/ai-commit-msg/src/schema.ts is either dead or inaccurate: either remove the
unused export or replace it with a complete, accurate list of supported model
names across google/openai/ollama and align it with the configSchema so the
model field is validated against that list (or derive the allowed values from
the same source used by configSchema). Locate the exported symbol models and the
configSchema in schema.ts, then either delete the models export if no code
imports it, or update models to include all supported model strings (and update
configSchema to restrict model to those strings or reference models) so the
snapshot and default config (llama2 with ollama) are consistent.
In `@core/ai-commit-msg/package.json`:
- Line 23: The package.json change made exports["."] point directly to
"./config/schema.mjs", removing the conditional import/require mapping and thus
dropping CommonJS support; revert to a conditional exports mapping (include both
"import" -> "./config/schema.mjs" and "require" -> "./config/schema.cjs" or
equivalent CommonJS entry) or explicitly document and bump the major version to
indicate the breaking ESM-only change; update the package.json exports field and
add or keep a CommonJS-compatible file (e.g., config/schema.cjs) if you choose
to preserve require consumers, and ensure package consumers are informed via
versioning and changelog.
- Line 27: The package.json "types" entry points to ./config/schema.d.cts which
is a CommonJS declaration while this package is ESM-only; update the types
reference to an ESM-compatible declaration (e.g., ./config/schema.d.mts or
./config/schema.d.ts) and ensure the build (the rollup/tsconfig/build step that
emits declarations) is configured to produce .d.mts outputs for the schema file
so TypeScript resolution matches the exports field and esm build format.
In `@core/ai-commit-msg/tsdown.config.ts`:
- Line 9: The commented attw configuration lines (attw: { 'profile': 'esm-only'
}) in tsdown.config.ts are ambiguous; decide whether ATTW checks should run and
then either remove both commented attw lines (if ATTW is no longer needed) or
uncomment them in both build entries to enable ESM-only validation, ensuring the
same change is applied to the occurrences referencing attw/profile 'esm-only' so
the config is consistent.
In `@core/astro-iconify-svgmap/tsdown.config.ts`:
- Line 2: The package's tsdown.config.ts imports ApiSnapshot from
"tsnapi/rolldown" but the package.json devDependencies do not declare tsnapi;
update the package.json devDependencies to include "tsnapi":
"catalog:typescript" (matching other workspace packages) so the import in
tsdown.config.ts (ApiSnapshot from "tsnapi/rolldown") resolves for standalone
installs and CI builds.
In `@core/auto-readme/__snapshots__/tsnapi/schema.snapshot.d.ts`:
- Line 5: The public type Config currently references a private symbol
`_configSchema`; replace that reference with the public symbol `configSchema`
(or create an equivalent exported type) so the public API does not leak
internals. Update the export of Config to use Partial<z.infer<typeof
configSchema>> (ensuring `configSchema` is exported) or define Config as an
independent exported interface/type matching the schema shape; adjust the
declaration in the snapshot to match the updated source.
In `@core/catppuccin-jsonresume-theme/__snapshots__/tsnapi/index.snapshot.d.ts`:
- Line 5: The snapshot is missing an import for the ResumeSchema type used in
the exported render signature; update the snapshot output so it is
self-contained by adding a type import or re-export for ResumeSchema (e.g. emit
`import type { ResumeSchema } from "./types";` or `export type { ResumeSchema }
from "./types";`) so the declaration `export declare function render(_:
ResumeSchema): string;` compiles; adjust the tsnapi snapshot generator code that
produces the declaration for render to include that import/re-export.
In `@core/catppuccin-jsonresume-theme/package.json`:
- Around line 22-26: The package.json change making the published entrypoint
ESM-only (the "exports" field pointing to "./dist/index.mjs" and the "types"
field "./dist/index.d.mts") must be called out as a breaking release: update the
release notes/changelog and PR title to include a clear "BREAKING CHANGE:
ESM-only package" entry and migration guidance for consumers using require(),
and consider adding an explicit "type":"module" to package.json to make the ESM
intent unambiguous; ensure the changelog explains how to migrate (use import or
dynamic import) and links to any helper steps or codemods.
In `@core/eslint-config/src/cli/index.ts`:
- Around line 3-5: The CLI currently calls run() at import time which causes
side effects; change the module so it only invokes run() when executed as the
entry script by guarding the call with a runtime entry check (e.g., use
require.main === module for CommonJS and import.meta.main for ESM) instead of
calling run() unconditionally; keep the exported run function intact so imports
of "./cli" remain side-effect-free and only execute run() when the entry check
passes.
In `@core/multipublish/package.json`:
- Line 27: The package.json "types" field currently points to a CommonJS
declaration "./config/schema.d.cts" while the package is ESM-only; update the
"types" entry to reference an ESM-compatible declaration (e.g.,
"./config/schema.d.mts" or a plain "./config/schema.d.ts") so the types format
matches the package's module type and tooling; modify the "types" value in
package.json accordingly and ensure the referenced declaration file exists and
is built as ESM.
- Line 23: Update package.json to reflect a breaking change by bumping the
"version" from 1.0.10 to 2.0.0 and ensure the exports/main fields accurately
represent the ESM-only change (the "exports" entry and removed "main"/require
mapping are the breaking surface); then update the CHANGELOG to add a clear
"Breaking Changes" entry describing removal of CommonJS support (exports now
only points to ./config/schema.mjs and main was removed) and note migration
guidance for consumers; make sure the package.json "exports" and "version" and
the CHANGELOG entry are consistent.
In `@core/single-file/package.json`:
- Around line 22-26: The exports map is missing TypeScript type entry points (so
importing `@stephansama/single-file/cli` loses types); update the "exports" object
to add "types" conditions for each entry (e.g., add a types path for "." and for
"./cli" pointing to the generated declaration files in dist, such as the .d.ts
equivalents of index.mjs and cli.mjs) and remove the top-level "types" field
once per-entry types are present; locate the "exports" block in package.json and
add the appropriate "types" keys referencing dist/*.d.ts for the corresponding
exports.
In `@core/single-file/src/cli.ts`:
- Around line 9-10: The file currently calls run() at module top-level which
executes on import; change this so run() only runs when the script is invoked as
a CLI by wrapping the top-level call in a "only when executed directly" guard
(e.g., check require.main === module for CommonJS or import.meta.main for ESM)
and invoke run() inside that guard (preserving the await behavior inside an
async wrapper), or if run() is not meant to be exported remove the export and
keep the top-level call; locate the current top-level await to the symbol run()
in cli.ts and apply the guard accordingly.
In `@core/typed-env/README.md`:
- Line 38: The README currently shows an incorrect local build import; update
the usage example to import the published package (use the package name to
import createEnvironment) instead of "../dist/index.mjs", or clearly label and
relocate the local-dev import under a separate "Development" section; ensure the
example uses createEnvironment from "@stephansama/typed-env" for the main usage
and keep any "../dist/index.mjs" reference only in a distinct development
subsection.
In `@core/typed-env/tsdown.config.ts`:
- Around line 2-10: The ApiSnapshot plugin is commented out so the package is
excluded from API snapshot generation; enable it by uncommenting the import of
ApiSnapshot and adding ApiSnapshot() into the plugins array passed to
defineConfig (i.e., restore the import line for ApiSnapshot and change the
commented "// plugins: [ApiSnapshot()]," to an active plugins: [ApiSnapshot()]
entry so the defineConfig call includes the plugin).
In `@core/typed-events/__snapshots__/tsnapi/index.snapshot.d.ts`:
- Line 33: The public type ListenerCallback references a non-exported symbol
AnyPayload which breaks the generated API; fix by exporting AnyPayload from its
defining module (where it is declared) or by inlining its definition into the
public API (so ListenerCallback no longer references an unexported type); locate
the AnyPayload declaration in the utils/types file and either add an export for
that type or replace the reference in ListenerCallback with the equivalent
exported type definition so the snapshot contains only exported symbols.
In `@core/typed-templates/__snapshots__/tsnapi/index.snapshot.d.ts`:
- Around line 1-8: The snapshot is missing an import for the referenced type
StandardSchemaV1 used by HandlebarSchemaMapOptions (and elsewhere); update the
tsnapi generation config or the generator plugin so the generated API includes
an import for StandardSchemaV1 (or add an explicit import for StandardSchemaV1
in the generated output) so the exported types (e.g., HandlebarSchemaMapOptions
and other occurrences) compile without errors.
In `@core/typed-templates/package.json`:
- Line 23: The export entry for "." was changed to a single ESM path
("./dist/index.mjs"), removing the conditional import/require map and breaking
CommonJS consumers; either restore a conditional export map (supporting both
"import" -> "./dist/index.mjs" and "require" ->
"./dist/index.cjs"/"./dist/index.js") in package.json, or if intentionally
ESM-only, update the changelog/migration guide to note the breaking change, bump
the package version appropriately (major per semver), and verify all consumers
support ESM before merging.
In `@core/types-lhci/README.md`:
- Line 36: Replace the repo-relative JSDoc type import /** `@type`
{import("../dist/index.d.mts").LhciSchema} */ with a package-qualified import
pointing at the published package that exports the type (e.g. /** `@type`
{import("<package-name>").LhciSchema} */); update the README example to use
import("<package-name>").LhciSchema (referencing the LhciSchema symbol) so
consumers copying the snippet get a resolving, package-scoped type
import—substitute <package-name> with the actual package that exports
LhciSchema.
---
Outside diff comments:
In `@core/astro-iconify-svgmap/package.json`:
- Line 42: The build script currently forces tsdown to run with --profile=node16
which conflicts with the project's ESM-only configuration in tsdown.config.ts
(attw.profile = "esm-only"); update the "build" script (the package.json "build"
entry that invokes tsdown) to stop passing --profile=node16 so tsdown uses the
tsdown.config.ts settings (or explicitly use --profile=esm-only if you prefer an
explicit flag), ensuring attw runs against the ESM-only exports consistent with
prepublishOnly.
---
Duplicate comments:
In `@core/multipublish/__snapshots__/tsnapi/index.snapshot.js`:
- Around line 1-6: The JS and TypeScript tsnapi snapshots disagree:
index.snapshot.js exports "async function run()" but index.snapshot.d.ts
declares no exports; regenerate the tsnapi snapshots so the public API contract
is consistent (either include run in the .d.ts or remove the run export from the
JS snapshot), e.g., run the project's tsnapi snapshot/regen command or the
tsnapi CLI to rebuild index.snapshot.js and index.snapshot.d.ts, verify the
export for run is present or absent in both, and commit the updated snapshots.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 5dd8a6cd-3a1c-47a8-ac88-34c79f56d05f
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (62)
.config/autoreadmerc.jsoncore/ai-commit-msg/__snapshots__/tsnapi/index.snapshot.jscore/ai-commit-msg/__snapshots__/tsnapi/schema.json.snapshot.d.tscore/ai-commit-msg/__snapshots__/tsnapi/schema.json.snapshot.jscore/ai-commit-msg/__snapshots__/tsnapi/schema.snapshot.d.tscore/ai-commit-msg/__snapshots__/tsnapi/schema.snapshot.jscore/ai-commit-msg/package.jsoncore/ai-commit-msg/tsdown.config.tscore/astro-iconify-svgmap/package.jsoncore/astro-iconify-svgmap/tsdown.config.tscore/auto-readme/__snapshots__/tsnapi/cli.snapshot.d.tscore/auto-readme/__snapshots__/tsnapi/cli.snapshot.jscore/auto-readme/__snapshots__/tsnapi/schema.snapshot.d.tscore/auto-readme/__snapshots__/tsnapi/schema.snapshot.jscore/auto-readme/cli.mjscore/auto-readme/package.jsoncore/auto-readme/src/cli.tscore/auto-readme/tsdown.config.tscore/catppuccin-jsonresume-theme/__snapshots__/tsnapi/index.snapshot.d.tscore/catppuccin-jsonresume-theme/__snapshots__/tsnapi/index.snapshot.jscore/catppuccin-jsonresume-theme/package.jsoncore/catppuccin-jsonresume-theme/tsdown.config.tscore/eslint-config/__snapshots__/tsnapi/cli.snapshot.d.tscore/eslint-config/__snapshots__/tsnapi/cli.snapshot.jscore/eslint-config/cli.mjscore/eslint-config/example/index.jscore/eslint-config/package.jsoncore/eslint-config/src/cli/index.tscore/eslint-config/tsdown.config.tscore/multipublish/__snapshots__/tsnapi/index.snapshot.jscore/multipublish/__snapshots__/tsnapi/schema.snapshot.d.tscore/multipublish/__snapshots__/tsnapi/schema.snapshot.jscore/multipublish/package.jsoncore/multipublish/tsdown.config.tscore/prettier-plugin-handlebars/example/index.jscore/remark-asciinema/example/index.jscore/single-file/cli.mjscore/single-file/example/index.jscore/single-file/package.jsoncore/single-file/src/cli.tscore/single-file/tsdown.config.tscore/typed-env/README.mdcore/typed-env/example/index.jscore/typed-env/tsdown.config.tscore/typed-events/README.mdcore/typed-events/__snapshots__/tsnapi/index.snapshot.d.tscore/typed-events/example/index.jscore/typed-events/package.jsoncore/typed-events/tsdown.config.tscore/typed-nocodb-api/example/index.jscore/typed-nocodb-api/package.jsoncore/typed-nocodb-api/tsdown.config.tscore/typed-templates/__snapshots__/tsnapi/index.snapshot.d.tscore/typed-templates/__snapshots__/tsnapi/index.snapshot.jscore/typed-templates/example/index.jscore/typed-templates/package.jsoncore/typed-templates/tsdown.config.tscore/types-lhci/README.mdcore/types-lhci/example/index.jscore/types-lhci/package.jsoncore/types-lhci/tsdown.config.tseslint.config.ts
💤 Files with no reviewable changes (3)
- core/auto-readme/cli.mjs
- core/eslint-config/cli.mjs
- core/single-file/cli.mjs
| OPENAI_API_KEY: z.ZodString; | ||
| }, z.core.$strip>; | ||
| }; | ||
| export declare const models: readonly ["gemini-2.5-flash"]; |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial | 💤 Low value
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Check source code for model definitions
echo "=== Searching for model definitions in source ==="
rg -n "gemini|models.*=|model.*:" core/ai-commit-msg/src/ --type=ts -C3Repository: stephansama/packages
Length of output: 2470
🏁 Script executed:
cat -n core/ai-commit-msg/src/schema.tsRepository: stephansama/packages
Length of output: 1820
🏁 Script executed:
cat -n core/ai-commit-msg/src/config.tsRepository: stephansama/packages
Length of output: 1093
🏁 Script executed:
# Search for any documentation about supported models
rg -i "model|gemini|llama" core/ai-commit-msg/README.md core/ai-commit-msg/package.json -C2Repository: stephansama/packages
Length of output: 380
🏁 Script executed:
# Check git history for recent changes to models definition
git log --oneline -n 20 -- core/ai-commit-msg/src/schema.tsRepository: stephansama/packages
Length of output: 162
🏁 Script executed:
rg "models" core/ai-commit-msg/src/ -n --type=tsRepository: stephansama/packages
Length of output: 232
🏁 Script executed:
# Check if models is exported and used elsewhere
rg -n "from.*schema.*models|import.*models" core/ai-commit-msg/ --type=tsRepository: stephansama/packages
Length of output: 46
The snapshot correctly reflects the source code, but the underlying source definition is incomplete.
The models constant in core/ai-commit-msg/src/schema.ts is hardcoded to ["gemini-2.5-flash"], but this constant is unused in the codebase (no imports found) and inconsistent with the default config, which uses "llama2" with the "ollama" provider. The configSchema also accepts any arbitrary string for the model field, making the hardcoded constant list ineffective. Either the constant should be removed if unused, or it should be updated to reflect all supported models across the three providers (google, openai, ollama).
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@core/ai-commit-msg/__snapshots__/tsnapi/schema.snapshot.d.ts` at line 35, The
models constant exported as models in core/ai-commit-msg/src/schema.ts is either
dead or inaccurate: either remove the unused export or replace it with a
complete, accurate list of supported model names across google/openai/ollama and
align it with the configSchema so the model field is validated against that list
(or derive the allowed values from the same source used by configSchema). Locate
the exported symbol models and the configSchema in schema.ts, then either delete
the models export if no code imports it, or update models to include all
supported model strings (and update configSchema to restrict model to those
strings or reference models) so the snapshot and default config (llama2 with
ollama) are consistent.
| "import": "./config/schema.mjs", | ||
| "require": "./config/schema.cjs" | ||
| }, | ||
| ".": "./config/schema.mjs", |
There was a problem hiding this comment.
Breaking change: ESM-only export eliminates CommonJS support.
The exports["."] field was changed from a conditional {import, require} mapping to a direct ESM-only path ./config/schema.mjs. This is a breaking change for any CommonJS consumers. Ensure this aligns with the package's compatibility requirements and that major version is bumped if needed.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@core/ai-commit-msg/package.json` at line 23, The package.json change made
exports["."] point directly to "./config/schema.mjs", removing the conditional
import/require mapping and thus dropping CommonJS support; revert to a
conditional exports mapping (include both "import" -> "./config/schema.mjs" and
"require" -> "./config/schema.cjs" or equivalent CommonJS entry) or explicitly
document and bump the major version to indicate the breaking ESM-only change;
update the package.json exports field and add or keep a CommonJS-compatible file
(e.g., config/schema.cjs) if you choose to preserve require consumers, and
ensure package consumers are informed via versioning and changelog.
| }, | ||
| "main": "./config/schema.cjs", | ||
| "module": "./config/schema.mjs", | ||
| "types": "./config/schema.d.cts", |
There was a problem hiding this comment.
Type declaration extension mismatch with ESM-only build.
The types field points to ./config/schema.d.cts (CommonJS type declarations), but the package is now ESM-only (line 23 exports only .mjs and the build format is ["esm"]). This mismatch can cause TypeScript resolution issues. Change the types field to use .d.mts or .d.ts to match the ESM module format.
🔧 Suggested fix
- "types": "./config/schema.d.cts",
+ "types": "./config/schema.d.mts",Ensure the build output generates .d.mts files instead of .d.cts.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@core/ai-commit-msg/package.json` at line 27, The package.json "types" entry
points to ./config/schema.d.cts which is a CommonJS declaration while this
package is ESM-only; update the types reference to an ESM-compatible declaration
(e.g., ./config/schema.d.mts or ./config/schema.d.ts) and ensure the build (the
rollup/tsconfig/build step that emits declarations) is configured to produce
.d.mts outputs for the schema file so TypeScript resolution matches the exports
field and esm build format.
| @@ -1,12 +1,14 @@ | |||
| import { defineConfig } from "tsdown"; | |||
| import ApiSnapshot from "tsnapi/rolldown"; | |||
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify tsnapi is declared somewhere in the workspace for this package
echo "=== Searching for tsnapi declarations ==="
fd -t f 'package.json' --exec rg -l '"tsnapi"' {} \;
echo ""
echo "=== pnpm-workspace catalog entries (if any) ==="
fd -t f 'pnpm-workspace.yaml' --exec cat {} \;
echo ""
echo "=== Direct usages of tsnapi across repo ==="
rg -nP '\btsnapi(/|"|\b)' -g '!**/dist/**' -g '!**/__snapshots__/**'Repository: stephansama/packages
Length of output: 7136
🏁 Script executed:
cat -n core/astro-iconify-svgmap/package.json | sed -n '40,60p'Repository: stephansama/packages
Length of output: 694
Add tsnapi to devDependencies in core/astro-iconify-svgmap/package.json.
The file imports tsnapi/rolldown at line 2, but tsnapi is not declared in the package's devDependencies (lines 48-54). While tsnapi is available through the workspace catalog, this package must explicitly declare it as a direct dependency. Without this declaration, the package will fail to build outside the monorepo or in isolated installations (e.g., when consumed standalone or in a fresh CI cache).
Add "tsnapi": "catalog:typescript" to the devDependencies block, consistent with how other packages in the workspace (e.g., core/eslint-config) declare it.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@core/astro-iconify-svgmap/tsdown.config.ts` at line 2, The package's
tsdown.config.ts imports ApiSnapshot from "tsnapi/rolldown" but the package.json
devDependencies do not declare tsnapi; update the package.json devDependencies
to include "tsnapi": "catalog:typescript" (matching other workspace packages) so
the import in tsdown.config.ts (ApiSnapshot from "tsnapi/rolldown") resolves for
standalone installs and CI builds.
| // import ApiSnapshot from "tsnapi/rolldown"; | ||
|
|
||
| export default defineConfig({ | ||
| attw: true, | ||
| dts: true, | ||
| entry: ["src/index.ts"], | ||
| exports: true, | ||
| format: ["esm", "cjs"], | ||
| // plugins: [ApiSnapshot()], |
There was a problem hiding this comment.
Enable ApiSnapshot instead of leaving scaffold commented out.
core/typed-env currently opts out of snapshot generation because both the import and plugin registration are commented. That leaves this package outside the PR’s API-snapshot workflow.
Suggested fix
import { defineConfig } from "tsdown";
-// import ApiSnapshot from "tsnapi/rolldown";
+import ApiSnapshot from "tsnapi/rolldown";
export default defineConfig({
attw: true,
dts: true,
entry: ["src/index.ts"],
exports: true,
format: ["esm", "cjs"],
- // plugins: [ApiSnapshot()],
+ plugins: [ApiSnapshot()],
publint: true,
target: "esnext",
});📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| // import ApiSnapshot from "tsnapi/rolldown"; | |
| export default defineConfig({ | |
| attw: true, | |
| dts: true, | |
| entry: ["src/index.ts"], | |
| exports: true, | |
| format: ["esm", "cjs"], | |
| // plugins: [ApiSnapshot()], | |
| import ApiSnapshot from "tsnapi/rolldown"; | |
| export default defineConfig({ | |
| attw: true, | |
| dts: true, | |
| entry: ["src/index.ts"], | |
| exports: true, | |
| format: ["esm", "cjs"], | |
| plugins: [ApiSnapshot()], |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@core/typed-env/tsdown.config.ts` around lines 2 - 10, The ApiSnapshot plugin
is commented out so the package is excluded from API snapshot generation; enable
it by uncommenting the import of ApiSnapshot and adding ApiSnapshot() into the
plugins array passed to defineConfig (i.e., restore the import line for
ApiSnapshot and change the commented "// plugins: [ApiSnapshot()]," to an active
plugins: [ApiSnapshot()] entry so the defineConfig call includes the plugin).
| // #endregion | ||
|
|
||
| // #region Types | ||
| export type ListenerCallback<Input, Keys extends keyof RawEventMap> = (_: AnyPayload<Input, Keys>) => void; |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Search for AnyPayload definition in the package
# Check if AnyPayload is defined in this snapshot file
echo "=== Checking index.snapshot.d.ts for AnyPayload definition ==="
rg -n 'type AnyPayload|interface AnyPayload|class AnyPayload' core/typed-events/__snapshots__/tsnapi/index.snapshot.d.ts
# Check other snapshot files
echo "=== Checking other snapshot files ==="
fd -e d.ts -e ts --full-path '__snapshots__/tsnapi' -x rg -l 'type AnyPayload|interface AnyPayload'
# Check source files for AnyPayload definition
echo "=== Checking source files ==="
rg -n --type=ts 'export.*AnyPayload' core/typed-events/src/Repository: stephansama/packages
Length of output: 195
🏁 Script executed:
# Read the full snapshot file to see imports and structure
cat -n core/typed-events/__snapshots__/tsnapi/index.snapshot.d.ts | head -50Repository: stephansama/packages
Length of output: 3163
🏁 Script executed:
# Check if there are any imports at the top of the file
head -20 core/typed-events/__snapshots__/tsnapi/index.snapshot.d.tsRepository: stephansama/packages
Length of output: 1213
🏁 Script executed:
# Search for any pattern like "Payload" in the file to understand similar types
rg -n 'Payload' core/typed-events/__snapshots__/tsnapi/index.snapshot.d.ts -A 1 -B 1Repository: stephansama/packages
Length of output: 243
🏁 Script executed:
# Check what tsnapi is and how snapshots are generated
fd -e json -e md --full-path 'tsnapi' core/typed-events/ | head -10Repository: stephansama/packages
Length of output: 46
🏁 Script executed:
# Look for README or config that explains snapshot generation
find core/typed-events -type f \( -name "README*" -o -name "tsconfig*" -o -name "*.config.*" \) | head -10Repository: stephansama/packages
Length of output: 194
🏁 Script executed:
# Find the actual source TypeScript files (not snapshots)
fd -e ts -p 'core/typed-events/src' --type fRepository: stephansama/packages
Length of output: 787
🏁 Script executed:
# Search for ListenerCallback definition in source files
rg -n 'ListenerCallback' core/typed-events/src/Repository: stephansama/packages
Length of output: 508
🏁 Script executed:
# Search for AnyPayload in the entire typed-events directory
rg -n 'AnyPayload' core/typed-events/Repository: stephansama/packages
Length of output: 403
🏁 Script executed:
# Read the source file to see both ListenerCallback and AnyPayload definitions
cat -n core/typed-events/src/utils/types.tsRepository: stephansama/packages
Length of output: 2515
AnyPayload is not exported, breaking the public API snapshot.
The exported ListenerCallback type on line 33 references AnyPayload<Input, Keys>, but this type is defined as private (not exported) in the source code at core/typed-events/src/utils/types.ts:62. When tsnapi generates the public API snapshot, it captures the exported ListenerCallback but omits the non-exported AnyPayload definition, creating a broken declaration where the public type references an undefined symbol.
Consumers using this snapshot file will encounter TypeScript compilation errors. Fix by either exporting AnyPayload from the source or inlining its definition in the snapshot.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@core/typed-events/__snapshots__/tsnapi/index.snapshot.d.ts` at line 33, The
public type ListenerCallback references a non-exported symbol AnyPayload which
breaks the generated API; fix by exporting AnyPayload from its defining module
(where it is declared) or by inlining its definition into the public API (so
ListenerCallback no longer references an unexported type); locate the AnyPayload
declaration in the utils/types file and either add an export for that type or
replace the reference in ListenerCallback with the equivalent exported type
definition so the snapshot contains only exported symbols.
| /** | ||
| * Generated by tsnapi — public API snapshot of `@stephansama/typed-templates` | ||
| */ | ||
| // #region Types | ||
| export type HandlebarSchemaMapOptions = { | ||
| path: string; | ||
| schema: StandardSchemaV1; | ||
| }; |
There was a problem hiding this comment.
Missing import for StandardSchemaV1 type.
The type StandardSchemaV1 is used on line 7 (and throughout the file on lines 16, 19, 23) but is never imported. This will cause TypeScript compilation errors.
Since this is a generated file, verify that the tsnapi configuration or plugin is set up to automatically include the necessary imports for referenced types.
📦 Expected import statement
/**
* Generated by tsnapi — public API snapshot of `@stephansama/typed-templates`
*/
+import type { StandardSchemaV1 } from '@standard-schema/spec';
+
// `#region` Types
export type HandlebarSchemaMapOptions = {
path: string;
schema: StandardSchemaV1;
};📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| /** | |
| * Generated by tsnapi — public API snapshot of `@stephansama/typed-templates` | |
| */ | |
| // #region Types | |
| export type HandlebarSchemaMapOptions = { | |
| path: string; | |
| schema: StandardSchemaV1; | |
| }; | |
| /** | |
| * Generated by tsnapi — public API snapshot of `@stephansama/typed-templates` | |
| */ | |
| import type { StandardSchemaV1 } from '@standard-schema/spec'; | |
| // `#region` Types | |
| export type HandlebarSchemaMapOptions = { | |
| path: string; | |
| schema: StandardSchemaV1; | |
| }; |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@core/typed-templates/__snapshots__/tsnapi/index.snapshot.d.ts` around lines 1
- 8, The snapshot is missing an import for the referenced type StandardSchemaV1
used by HandlebarSchemaMapOptions (and elsewhere); update the tsnapi generation
config or the generator plugin so the generated API includes an import for
StandardSchemaV1 (or add an explicit import for StandardSchemaV1 in the
generated output) so the exported types (e.g., HandlebarSchemaMapOptions and
other occurrences) compile without errors.
| "import": "./dist/index.mjs", | ||
| "require": "./dist/index.cjs" | ||
| }, | ||
| ".": "./dist/index.mjs", |
There was a problem hiding this comment.
Breaking change: ESM-only exports.
The removal of the conditional import/require export map in favor of a direct ESM path ("./dist/index.mjs") is a breaking change that drops CommonJS support. This will prevent CommonJS consumers from loading the package.
Verify that:
- This breaking change is documented in the changelog/migration guide
- The package version will be bumped appropriately (major version if following semver)
- All known consumers of this package support ESM
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@core/typed-templates/package.json` at line 23, The export entry for "." was
changed to a single ESM path ("./dist/index.mjs"), removing the conditional
import/require map and breaking CommonJS consumers; either restore a conditional
export map (supporting both "import" -> "./dist/index.mjs" and "require" ->
"./dist/index.cjs"/"./dist/index.js") in package.json, or if intentionally
ESM-only, update the changelog/migration guide to note the breaking change, bump
the package version appropriately (major per semver), and verify all consumers
support ESM before merging.
| import { lhciSchema } from "@stephansama/types-lhci"; | ||
|
|
||
| /** @type {import("../dist/index.d.cts").LhciSchema} */ | ||
| /** @type {import("../dist/index.d.mts").LhciSchema} */ |
There was a problem hiding this comment.
Use package-qualified type import in the README example.
Line 36 points to a repo-relative declaration path that won’t resolve for most consumers copying this snippet. Prefer importing the type from the package name directly.
💡 Suggested fix
-/** `@type` {import("../dist/index.d.mts").LhciSchema} */
+/** `@type` {import("@stephansama/types-lhci").LhciSchema} */📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| /** @type {import("../dist/index.d.mts").LhciSchema} */ | |
| /** `@type` {import("@stephansama/types-lhci").LhciSchema} */ |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@core/types-lhci/README.md` at line 36, Replace the repo-relative JSDoc type
import /** `@type` {import("../dist/index.d.mts").LhciSchema} */ with a
package-qualified import pointing at the published package that exports the type
(e.g. /** `@type` {import("<package-name>").LhciSchema} */); update the README
example to use import("<package-name>").LhciSchema (referencing the LhciSchema
symbol) so consumers copying the snippet get a resolving, package-scoped type
import—substitute <package-name> with the actual package that exports
LhciSchema.
@stephansama/ai-commit-msg
@stephansama/alfred-kaomoji
@stephansama/astro-iconify-svgmap
@stephansama/auto-readme
@stephansama/catppuccin-jsonresume-theme
@stephansama/catppuccin-opml
@stephansama/catppuccin-rss
@stephansama/catppuccin-typedoc
@stephansama/catppuccin-xsl
@stephansama/eslint-config
create-stephansama-example
@stephansama/find-makefile-targets
@stephansama/github-env
@stephansama/multipublish
@stephansama/prettier-plugin-handlebars
@stephansama/remark-asciinema
@stephansama/single-file
@stephansama/svelte-social-share-links
@stephansama/typed-env
@stephansama/typed-events
@stephansama/typed-nocodb-api
@stephansama/typed-templates
@stephansama/types-github-action-env
@stephansama/types-lhci
commit: |
Checklist
mainhave been mergedmain