feat: rename composite functionality to recurrence #35
Conversation
WalkthroughThis change removes all references to "composite" Pix element types and replaces them with "recurrence" Pix element types throughout the codebase. All related types, functions, validation, parsing, and tests are updated to support recurrence Pix elements instead of composite Pix elements, unifying the logic and exported interfaces. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant API
participant RecurrencePixCreator
participant RecurrencePixAssembler
User->>API: Call createRecurrencePix(params)
API->>RecurrencePixCreator: Validate and prepare recurrence params
RecurrencePixCreator->>RecurrencePixAssembler: Assemble recurrence Pix object
RecurrencePixAssembler->>RecurrencePixCreator: Return recurrence Pix object
RecurrencePixCreator->>API: Return recurrence Pix object or error
API->>User: Return result
Possibly related PRs
Suggested labels
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
✨ Finishing Touches
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
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: 1
🔭 Outside diff range comments (1)
src/assembler.ts (1)
33-39:⚠️ Potential issuePotential runtime error with undefined
urlRecin dynamic elements.The
fetchRecPayloadfunction is called unconditionally withelements.urlRecfor dynamic elements, buturlReccan be undefined for dynamic PIX elements. This could cause runtime errors whenfetchRecPayloadis called with an undefined URL.Consider adding a conditional check similar to the static case:
...(elements.type === PixElementType.DYNAMIC ? { fetchPayload: ({ DPP, codMun }) => fetchPayload({ url: elements.url, DPP, codMun }), - fetchRecPayload: () => fetchRecPayload({ url: elements.urlRec }), + ...(elements.urlRec + ? { + fetchRecPayload: () => fetchRecPayload({ url: elements.urlRec }), + } + : {}), } : {}),
🧹 Nitpick comments (2)
tests/extractor.test.ts (1)
57-57: Update test description to match test content.The test description still says "dynamic pix" but the test is actually testing recurrence PIX functionality using
RECURRENCE_DYNAMIC_UNRESERVED_EMV.Apply this diff to fix the test description:
- it('should be able to extract basic elements from a dynamic pix', () => { + it('should be able to extract basic elements from a recurrence pix', () => {src/types/pixElements.ts (1)
1-75: Well-executed refactoring with clear architectural improvements.The composite-to-recurrence refactoring demonstrates thoughtful design:
- Clear separation: Recurrence PIX elements have distinct URL handling (
urlReconly)- Flexibility: Dynamic PIX can optionally support recurrence via
urlRec- Type safety: All type mappings are consistently updated
- Breaking changes: Properly documented in PR objectives
Ensure migration documentation is provided for users upgrading from composite to recurrence functionality.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (13)
src/assembler.ts(1 hunks)src/create.ts(3 hunks)src/emvHandler.ts(2 hunks)src/index.ts(1 hunks)src/parser.ts(3 hunks)src/types/pixCreate.ts(1 hunks)src/types/pixElements.ts(4 hunks)src/types/pixFunctions.ts(2 hunks)src/validate.ts(4 hunks)tests/creator.test.ts(4 hunks)tests/emvCodes.ts(1 hunks)tests/extractor.test.ts(2 hunks)tests/parser.test.ts(6 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (8)
tests/parser.test.ts (4)
tests/emvCodes.ts (3)
RECURRENCE_STATIC_UNRESERVED_EMV(24-25)RECURRENCE_DYNAMIC_UNRESERVED_EMV(30-31)RECURRENCE_DYNAMIC_UNRESERVED_REC(33-34)src/index.ts (1)
parsePix(6-6)src/parser.ts (1)
parsePix(20-36)src/types/pixElements.ts (2)
PixStaticObject(70-70)PixRecurrenceObject(74-74)
tests/creator.test.ts (4)
src/index.ts (3)
createDynamicPix(2-2)hasError(8-8)createRecurrencePix(4-4)src/create.ts (2)
createDynamicPix(55-74)createRecurrencePix(76-96)src/validate.ts (1)
hasError(48-52)tests/emvCodes.ts (3)
RECURRENCE_DYNAMIC_UNRESERVED_EMV(30-31)RECURRENCE_STATIC_UNRESERVED_EMV2(27-28)RECURRENCE_REC_ONLY(36-37)
src/types/pixFunctions.ts (3)
src/dynamicPayload.ts (1)
PIXFetchResults(8-17)src/types/pixError.ts (1)
PixError(1-5)src/types/pixElements.ts (2)
PixDynamicObject(72-72)PixRecurrenceObject(74-74)
src/assembler.ts (1)
src/dynamicPayload.ts (1)
fetchRecPayload(76-102)
src/validate.ts (3)
src/types/pixEmvSchema.ts (1)
ValidTags(45-61)src/index.ts (1)
isRecurrencePix(11-11)src/types/pixElements.ts (2)
PixObjects(68-68)PixRecurrenceObject(74-74)
src/parser.ts (1)
src/validate.ts (1)
isPix(12-46)
src/create.ts (5)
src/index.ts (2)
createRecurrencePix(4-4)PixError(13-13)src/types/pixCreate.ts (1)
CreateRecurrencePixParams(22-27)src/types/pixElements.ts (2)
PixRecurrenceObject(74-74)RecurrencePixEmvElements(29-33)src/types/pixError.ts (1)
PixError(1-5)src/assembler.ts (1)
generatePixObject(15-51)
src/types/pixElements.ts (1)
src/types/pixFunctions.ts (1)
PixRecurrenceFn(32-35)
🔇 Additional comments (36)
src/index.ts (1)
4-4: LGTM: Clean export renaming consistent with refactoring.The export statements correctly update from composite to recurrence terminology, maintaining the same structure and functionality while aligning with the overall refactoring objectives.
Also applies to: 11-11
src/emvHandler.ts (1)
30-30: LGTM: Consistent enum value updates.The changes correctly replace
PixElementType.COMPOSITEwithPixElementType.RECURRENCEin both conditional checks, maintaining the same logic flow while supporting the new element type.Also applies to: 49-49
src/types/pixCreate.ts (1)
18-18: LGTM: Improved type safety and logical separation.The type changes effectively separate dynamic and recurrence PIX functionality:
CreateDynamicPixParamsnow includes optionalurlRecfor flexibilityCreateRecurrencePixParamsrequiresurlRecas mandatory, improving type safety- The removal of the optional
urlproperty from recurrence params makes the distinction clearThis design better reflects the intended usage patterns described in the PR objectives.
Also applies to: 22-27
tests/parser.test.ts (5)
5-5: Import update correctly reflects the refactoring.The import of
PixRecurrenceObjectreplacingPixCompositeObjectaligns with the systematic refactoring from composite to recurrence functionality.
16-18: EMV code constants properly updated for recurrence functionality.The import updates from
COMPOSITE_toRECURRENCE_prefixed constants are consistent with the broader refactoring effort and maintain the same test coverage.Also applies to: 22-22
40-40: Test data correctly updated to use recurrence EMV codes.The usage of
RECURRENCE_STATIC_UNRESERVED_EMVinstead of the previous composite constants ensures tests are validating the new recurrence functionality while maintaining the same test logic.Also applies to: 142-142
177-180: Type classification for recurrence-only EMV codes is correct.The test correctly expects type
'RECURRENCE'for EMV codes that contain only recurrence URL data without a standard dynamic URL, which aligns with the new recurrence functionality design.
158-161:✅ Verification successful
Verify the type expectation change from COMPOSITE to DYNAMIC.
The test now expects type
'DYNAMIC'instead of'COMPOSITE'for the recurrence dynamic EMV code. This suggests that recurrence functionality now leverages dynamic PIX types rather than a separate composite type.
🏁 Script executed:
#!/bin/bash # Description: Verify how recurrence EMV codes are classified in the parser logic # Expected: Find logic that determines when a PIX object should be DYNAMIC vs RECURRENCE # Search for type determination logic in parser ast-grep --pattern $'if ($$$) { $$$ type: PixElementType.DYNAMIC $$$ }' # Search for RECURRENCE type determination ast-grep --pattern $'if ($$$) { $$$ type: PixElementType.RECURRENCE $$$ }' # Look for the specific classification logic rg -A 10 -B 5 "PixElementType\.(DYNAMIC|RECURRENCE)" src/Length of output: 8748
Recurrence dynamic EMV codes correctly classified as DYNAMIC
The parser’sisPix(emvElements, 'dynamic')branch (src/parser.ts) handles both one-time and recurrence-dynamic PIX codes, returningPixElementType.DYNAMIC. Expecting'DYNAMIC'in the test aligns with this implementation.tests/emvCodes.ts (1)
24-36: Constant renaming is consistent and preserves EMV code values.The systematic renaming from
COMPOSITE_toRECURRENCE_prefix maintains the actual EMV code string values while updating the semantic meaning to align with the recurrence functionality refactoring.tests/creator.test.ts (5)
3-3: Import update correctly reflects the new recurrence functionality.The import of
createRecurrencePixreplacingcreateCompositePixaligns with the systematic refactoring from composite to recurrence functionality.
10-12: EMV code constant imports properly updated.The import updates from
COMPOSITE_toRECURRENCE_prefixed constants maintain test coverage while aligning with the refactored functionality.
154-167: Static PIX with recurrence URL correctly uses createStaticPix.The test correctly uses
createStaticPixfor creating a static PIX withurlRec, which aligns with the expected functionality where static PIX can optionally include recurrence URLs.
169-180: Recurrence-only PIX correctly uses createRecurrencePix.The test properly uses
createRecurrencePixfor creating PIX objects that only contain recurrence URL data without standard PIX key or dynamic URL, which aligns with the new recurrence functionality design.
138-152:❓ Verification inconclusive
Verify function usage consistency with test description.
The test description indicates "create a recurrence pix" but uses
createDynamicPixinstead ofcreateRecurrencePix. This might be correct if recurrence PIX with bothurlandurlRecshould be created as dynamic PIX objects, but it's worth confirming.
🏁 Script executed:
#!/bin/bash # Description: Verify the correct function to use for creating PIX with both url and urlRec # Expected: Understand when to use createDynamicPix vs createRecurrencePix # Search for function signatures and usage patterns ast-grep --pattern $'createDynamicPix({ $$$ urlRec: $_ $$$ })' ast-grep --pattern $'createRecurrencePix({ $$$ url: $_ $$$ })' # Look at the function implementations to understand the difference rg -A 15 "export function createDynamicPix" src/ rg -A 15 "export function createRecurrencePix" src/Length of output: 1770
🏁 Script executed:
#!/bin/bash # Fetch type definitions for CreateDynamicPixParams and CreateRecurrencePixParams rg -A 10 "CreateDynamicPixParams" src/ rg -A 10 "CreateRecurrencePixParams" src/Length of output: 2769
🏁 Script executed:
#!/bin/bash # Inspect generateEmv definition and its type-based logic rg -A 20 -n "function generateEmv" src/Length of output: 1352
}
🏁 Script executed:
#!/bin/bash rg -A 10 "interface PixDynamicObject" src/types rg -A 10 "interface PixRecurrenceObject" src/typesLength of output: 102
Further verification of PIX generation logic needed to confirm correct use of
createDynamicPixvscreateRecurrencePix. Please manually check that:
createDynamicPixproduces an EMV string withPixElementType.DYNAMIC, suitable when bothurlandurlRecparameters coexist.createRecurrencePixproduces an EMV string withPixElementType.RECURRENCE, using onlyurlRec.Ensure the test at tests/creator.test.ts:138–152 is invoking the function that aligns with the expected EMV type:
• If you intend to test a Dynamic PIX with recurrence support (both URLs), keep
createDynamicPix.
• If you intend to test a Recurrence PIX (onlyurlRec), switch tocreateRecurrencePix.src/types/pixFunctions.ts (3)
4-4: Import update correctly reflects the type refactoring.The import of
PixRecurrenceObjectreplacingPixCompositeObjectaligns with the systematic refactoring from composite to recurrence functionality.
28-28: Optional fetchRecPayload method correctly added to PixDynamicFn.Adding the optional
fetchRecPayloadmethod toPixDynamicFnallows dynamic PIX objects to optionally support recurrence functionality, which aligns with the design where dynamic PIX can include recurrence URLs.
32-35: PixRecurrenceFn interface correctly replaces PixCompositeFn.The new
PixRecurrenceFninterface properly defines recurrence PIX functionality with:
- Required
fetchRecPayloadmethod (vs optional in dynamic)- Correct return type of
PixRecurrenceObjectforthrowIfErrorThis design correctly distinguishes recurrence PIX objects from dynamic PIX objects.
src/assembler.ts (1)
40-44: LGTM! Recurrence type handling looks correct.The replacement of COMPOSITE with RECURRENCE type handling is implemented correctly. The
fetchRecPayloadfunction is appropriately provided for recurrence elements, and the logic aligns with the PR objectives.src/create.ts (3)
4-4: LGTM! Import changes are consistent with the refactoring.The import statement correctly replaces
CreateCompositePixParamswithCreateRecurrencePixParams, aligning with the broader renaming from composite to recurrence functionality.
9-14: LGTM! Type imports updated correctly.The imports properly replace composite-related types with their recurrence counterparts, maintaining type safety throughout the refactoring.
76-96: LGTM! Function refactoring is well-implemented.The
createRecurrencePixfunction correctly:
- Uses the new
CreateRecurrencePixParamstype- Sets
type: PixElementType.RECURRENCE- Explicitly sets
url: undefinedfor recurrence elements- Maintains consistent validation logic
- Returns the properly typed
PixRecurrenceObjectThe implementation aligns well with the PR objectives of clarifying recurrence vs dynamic payment handling.
src/parser.ts (4)
54-54: LGTM! Variable renaming is consistent with the refactoring.The change from
isCompositetoisRecurrencecorrectly aligns with the broader renaming initiative while maintaining the same validation logic.
75-81: LGTM! Static element handling updated correctly.The conditional assignment of
urlRecfor static elements now properly usesisRecurrenceinstead ofisComposite, maintaining the same logic while using the updated terminology.
89-95: LGTM! Dynamic element handling enhanced appropriately.The addition of
urlRechandling to dynamic elements based on theisRecurrenceflag aligns with the PR objective of allowing dynamic PIX payments to optionally include a recurrence URL.
98-108: LGTM! Recurrence element parsing implemented correctly.The replacement of the composite case with recurrence case is well-implemented:
- Uses
PixElementType.RECURRENCE- Explicitly sets
url: undefined- Properly extracts
urlRecfrom the unreserved templateThe logic correctly reflects the new recurrence element structure.
src/validate.ts (6)
6-6: LGTM! Import statement updated correctly.The import change from
PixCompositeObjecttoPixRecurrenceObjectis consistent with the refactoring and maintains type safety.
14-14: LGTM! Function parameter type updated appropriately.The
testparameter type correctly replaces'composite'with'recurrence', maintaining consistency with the renaming initiative.
27-30: LGTM! Variable renaming is consistent.The change from
isCompositetoisRecurrencemaintains the same validation logic while using the updated terminology. The tag checking remains unchanged, which is correct.
36-36: LGTM! Valid case logic updated correctly.The
validcase now properly includesisRecurrenceinstead ofisComposite, maintaining the same validation semantics with the updated naming.
41-42: LGTM! Switch case updated appropriately.The replacement of the
'composite'case with'recurrence'is correctly implemented, returning the appropriate boolean value for recurrence validation.
72-76: LGTM! Type guard function renamed and updated correctly.The
isRecurrencePixfunction properly:
- Uses the new function name
- Returns the correct
PixRecurrenceObjecttype- Checks for
PixElementType.RECURRENCEThe implementation maintains type safety while aligning with the refactoring objectives.
src/types/pixElements.ts (5)
2-2: LGTM: Import statement correctly updated for recurrence functionality.The import change from
PixCompositeFntoPixRecurrenceFnproperly aligns with the composite-to-recurrence refactoring.
26-26: Well-designed addition of optional recurrence support to dynamic PIX.Adding the optional
urlRecproperty allows dynamic PIX payments to support recurrence functionality while maintaining backward compatibility.
29-33: Excellent design for clear separation of URL handling.The
RecurrencePixEmvElementsinterface effectively separates recurrence PIX from dynamic PIX by:
- Explicitly setting
urltoundefined- Making
urlRecrequiredThis design prevents confusion and ensures recurrence elements use only the appropriate URL type.
54-74: Consistent type system updates for recurrence functionality.All type mappings, unions, and composite types are correctly updated to use the new
RECURRENCEelement type andRecurrencePixEmvElementsinterface. The pattern follows existing conventions and maintains type safety.
19-19:✅ Verification successful
Verify all references to COMPOSITE are updated throughout the codebase.
The enum value change from
COMPOSITEtoRECURRENCEis correct for the refactoring, but this is a breaking change that requires updating all references throughout the codebase.
🏁 Script executed:
#!/bin/bash # Search for any remaining references to COMPOSITE that might have been missed rg -i "composite" --type ts --type js | grep -v "node_modules" | head -20Length of output: 71
🏁 Script executed:
#!/bin/bash # Re-run a more targeted search for any leftover references to COMPOSITE rg -w "COMPOSITE" -g "!node_modules/*" rg "PixElementType\.COMPOSITE" -g "!node_modules/*" rg "\"composite\"" -g "!node_modules/*"Length of output: 197
No remaining
COMPOSITEreferences; change is containedA targeted search across TypeScript and JavaScript files confirmed there are no lingering references to
PixElementType.COMPOSITE. The only match ("composite": trueinexamples/example-react/tsconfig.node.json) is the TypeScript project setting and unrelated to the enum.All enum references have been updated to
RECURRENCE. No further action is required.
# [2.8.0](v2.7.1...v2.8.0) (2025-05-28) ### Features * rename composite functionality to recurrence ([#35](#35)) ([5ebee6a](5ebee6a))
|
🎉 This issue has been resolved in version 2.8.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
This is a feature change that involves renaming and restructuring the "composite" functionality to "recurrence" in the PIX payment system implementation.
The codebase currently uses the term "composite" to handle PIX payments that can have both dynamic and static elements, with support for recurring payments through a URL structure. The current implementation has some inconsistencies in how it handles the composite functionality, particularly in the way it manages URLs for both dynamic and recurring payments.
The new behavior introduces a clearer separation between dynamic and recurring payments:
Renames all "composite" related code to "recurrence" for better clarity
Restructures the URL handling:
Dynamic PIX can now optionally include a recurrence URL
Recurrence PIX is now a distinct type with its own URL structure
Improves type definitions and interfaces:
New PixRecurrenceObject type replaces PixCompositeObject
Updated function interfaces to better handle recurrence cases
Updates all test cases to reflect the new naming and structure
Simplifies the EMV code generation and parsing logic
Summary by CodeRabbit
New Features
Bug Fixes
Documentation
Refactor
Tests