Conversation
🦋 Changeset detectedLatest commit: caa31bb The changes in this PR will be included in the next version bump. This PR includes changesets to release 19 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.
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review infoConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro 📒 Files selected for processing (7)
📝 WalkthroughWalkthroughAdds type-safe BlockNumberRange and BlockRefRange abstractions with factory builders and runtime validation to two SDK packages, plus unit tests and a changeset; re-exports the module from ponder-sdk while ensnode-sdk's export remains commented out. Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Pull request overview
Adds a new discriminated-union data model and builder utilities for “block ranges” (bounded/unbounded, left/right-bounded) to both @ensnode/ensnode-sdk and @ensnode/ponder-sdk, plus tests and a changeset, as part of consolidating block range representations.
Changes:
- Introduces
RangeTypeIds,BlockNumberRange/BlockRefRangeunions, andbuildBlockNumberRange/buildBlockRefRangehelpers in both SDKs. - Exposes the new helpers/types via each package’s public
src/index.ts. - Adds Vitest coverage for the new builders and a changeset for versioning.
Reviewed changes
Copilot reviewed 7 out of 7 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| packages/ponder-sdk/src/index.ts | Re-exports new blockrange module from Ponder SDK entrypoint. |
| packages/ponder-sdk/src/blockrange.ts | New block range data model + builders for Ponder SDK. |
| packages/ponder-sdk/src/blockrange.test.ts | Unit tests for Ponder SDK block range builders. |
| packages/ensnode-sdk/src/shared/blockrange.ts | New shared block range data model + builders for ENSNode SDK. |
| packages/ensnode-sdk/src/shared/blockrange.test.ts | Unit tests for ENSNode SDK block range builders. |
| packages/ensnode-sdk/src/index.ts | Exposes shared blockrange from ENSNode SDK entrypoint (currently causes an export-name collision). |
| .changeset/smart-vans-stare.md | Declares minor bumps for both packages (contains a spelling error). |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Greptile SummaryThis PR introduces a streamlined and type-safe data model for block ranges in both the ENSNode SDK and Ponder SDK. The implementation uses discriminated unions with four range types ( Key changes:
Issues found:
Confidence Score: 5/5
Important Files Changed
Class Diagram%%{init: {'theme': 'neutral'}}%%
classDiagram
class BlockNumberRange {
<<union>>
}
class BlockNumberRangeUnbounded {
+rangeType: "unbounded"
}
class BlockNumberRangeLeftBounded {
+rangeType: "left-bounded"
+startBlock: BlockNumber
}
class BlockNumberRangeRightBounded {
+rangeType: "right-bounded"
+endBlock: BlockNumber
}
class BlockNumberRangeBounded {
+rangeType: "bounded"
+startBlock: BlockNumber
+endBlock: BlockNumber
}
class BlockRefRange {
<<union>>
}
class BlockRefRangeUnbounded {
+rangeType: "unbounded"
}
class BlockRefRangeLeftBounded {
+rangeType: "left-bounded"
+startBlock: BlockRef
}
class BlockRefRangeRightBounded {
+rangeType: "right-bounded"
+endBlock: BlockRef
}
class BlockRefRangeBounded {
+rangeType: "bounded"
+startBlock: BlockRef
+endBlock: BlockRef
}
BlockNumberRange <|-- BlockNumberRangeUnbounded
BlockNumberRange <|-- BlockNumberRangeLeftBounded
BlockNumberRange <|-- BlockNumberRangeRightBounded
BlockNumberRange <|-- BlockNumberRangeBounded
BlockRefRange <|-- BlockRefRangeUnbounded
BlockRefRange <|-- BlockRefRangeLeftBounded
BlockRefRange <|-- BlockRefRangeRightBounded
BlockRefRange <|-- BlockRefRangeBounded
Last reviewed commit: 585cb38 |
585cb38 to
d5dcf65
Compare
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.changeset/smart-vans-stare.md:
- Line 6: The changeset description in .changeset/smart-vans-stare.md contains a
spelling mistake: replace the word "Introcudes" with the correct "Introduces" so
the release notes read "Introduces streamlined datamodel for block ranges.";
update that exact token in the file to fix the typo.
In `@packages/ensnode-sdk/src/index.ts`:
- Line 13: The package index re-exports two different BlockRefRange types via
wildcard exports (from shared/blockrange and
indexing-status/chain-indexing-status-snapshot), causing a duplicate export
error; fix by updating the exports in index.ts to avoid exporting both
conflicting symbols: either explicitly re-export only the desired BlockRefRange
from shared/blockrange and remove BlockRefRange from the indexing-status export
(use named exports like export { BlockRefRange as ... } or omit it), or rename
the type in indexing-status (e.g., BlockRefRangeIndefinite/Definite ->
ChainBlockRefRange) and update its export so that only one BlockRefRange
identifier is exported; reference the modules shared/blockrange and
indexing-status/chain-indexing-status-snapshot and the symbol BlockRefRange when
making the change.
ℹ️ Review info
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (7)
.changeset/smart-vans-stare.mdpackages/ensnode-sdk/src/index.tspackages/ensnode-sdk/src/shared/blockrange.test.tspackages/ensnode-sdk/src/shared/blockrange.tspackages/ponder-sdk/src/blockrange.test.tspackages/ponder-sdk/src/blockrange.tspackages/ponder-sdk/src/index.ts
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 7 out of 7 changed files in this pull request and generated no new comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (1)
packages/ensnode-sdk/src/index.ts (1)
13-14:⚠️ Potential issue | 🟠 MajorBlockrange API remains inaccessible from the SDK root entrypoint due to unresolved export conflict.
The
./shared/blockrangeexport (line 14) stays commented out because bothblockrange.tsandchain-indexing-status-snapshot.tsexport incompatibleBlockRefRangetypes. The blockrange variant usesrangeTypewith Unbounded/LeftBounded/RightBounded/Bounded states, while the indexing-status variant usesblockRangeTypewith Indefinite/Definite states—these cannot coexist in the same namespace without aliasing or renaming.Resolve this before release by either:
- Renaming one
BlockRefRangetype (e.g., toBlockRefRangeIndexingConfigin indexing-status)- Using explicit re-exports with aliases in
index.ts- Or defer the blockrange feature exposure claim from this PR
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/ensnode-sdk/src/index.ts` around lines 13 - 14, The SDK root export for BlockRefRange is commented out because two symbols named BlockRefRange conflict: the variant in ./shared/blockrange (uses rangeType with Unbounded/LeftBounded/RightBounded/Bounded) and the variant in chain-indexing-status-snapshot (uses blockRangeType with Indefinite/Definite). Fix by either renaming one exported type (e.g., change the type name in chain-indexing-status-snapshot.ts to BlockRefRangeIndexingConfig) or add explicit aliased re-exports in index.ts (e.g., export { BlockRefRange as BlockRefRangeBlockrange } from "./shared/blockrange" and export { BlockRefRange as BlockRefRangeIndexingConfig } from "./chain-indexing-status-snapshot") so both APIs can be exposed without collision, then uncomment the export line for ./shared/blockrange.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@packages/ensnode-sdk/src/shared/blockrange.ts`:
- Around line 44-49: Convert the interfaces that document the invariants into
type aliases and move the invariant JSDoc there: replace the interface
declaration for the bounded block range (currently documenting "startBlock is
lower than or equal to endBlock") with a type alias (e.g., BlockRangeBounded)
and do the same for BlockRefRangeBounded; remove the duplicate invariant comment
from the corresponding builder functions (the builder that constructs the
bounded block range and the builder for BlockRefRangeBounded) so the invariant
is only documented once on the type alias; ensure the type alias names and
builder function signatures remain unchanged so callers are unaffected.
In `@packages/ponder-sdk/src/blockrange.ts`:
- Around line 43-48: Remove the duplicated invariant comments that repeat the
documentation already declared on the type aliases; specifically, delete the
inline comment lines that restate "`startBlock` is lower than or equal to
`endBlock`" in the implementation blocks for BlockNumberRangeBounded and
BlockRefRangeBounded so the invariant remains documented only on the
corresponding type alias declarations (BlockNumberRangeBounded,
BlockRefRangeBounded).
---
Duplicate comments:
In `@packages/ensnode-sdk/src/index.ts`:
- Around line 13-14: The SDK root export for BlockRefRange is commented out
because two symbols named BlockRefRange conflict: the variant in
./shared/blockrange (uses rangeType with
Unbounded/LeftBounded/RightBounded/Bounded) and the variant in
chain-indexing-status-snapshot (uses blockRangeType with Indefinite/Definite).
Fix by either renaming one exported type (e.g., change the type name in
chain-indexing-status-snapshot.ts to BlockRefRangeIndexingConfig) or add
explicit aliased re-exports in index.ts (e.g., export { BlockRefRange as
BlockRefRangeBlockrange } from "./shared/blockrange" and export { BlockRefRange
as BlockRefRangeIndexingConfig } from "./chain-indexing-status-snapshot") so
both APIs can be exposed without collision, then uncomment the export line for
./shared/blockrange.
ℹ️ Review info
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (7)
.changeset/smart-vans-stare.mdpackages/ensnode-sdk/src/index.tspackages/ensnode-sdk/src/shared/blockrange.test.tspackages/ensnode-sdk/src/shared/blockrange.tspackages/ponder-sdk/src/blockrange.test.tspackages/ponder-sdk/src/blockrange.tspackages/ponder-sdk/src/index.ts
Same types and utils have been added to ENSNode SDK and Ponder SDK.
bb79f21 to
caa31bb
Compare
Same types and utils have been added to ENSNode SDK and Ponder SDK.
Lite PR
Tip: Review docs on the ENSNode PR process
Summary
buildBlockNumberRangeandbuildBlockRefRangefunctions, along with relevant data model, to ENSNode SDK and Ponder SDK.Why
Testing
Notes for Reviewer (Optional)
Pre-Review Checklist (Blocking)