inconsistent space in postings and optional space in posting cost #383
Conversation
Signed-off-by: Kilerd Chan <[email protected]>
|
These test cases look enough to me. Maybe I would add some comments in the BTW, you spelled "consistent" wrong. |
sure, np |
Signed-off-by: Kilerd Chan <[email protected]>
Kilerd
changed the title
Signed-off-by: Kilerd Chan <[email protected]>
Kilerd
force-pushed
the
381-cannot-parse-comment-lines-betwen-actual-postings
branch
from
ee8d5b3 to
78ef4fc
Compare
|
@CodeRabbit review |
✅ Actions performedReview triggered.
|
WalkthroughThe pull request introduces several modifications across multiple files, primarily enhancing GitHub Actions workflows for setting up Python in the Changes
Possibly related PRs
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
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 (
|
Signed-off-by: Kilerd Chan <[email protected]>
|
@CodeRabbit review |
✅ Actions performedReview triggered.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 12
🧹 Outside diff range and nitpick comments (15)
integration-tests/inconsistent-indent-for-postings/validations.json (1)
1-11: Add a comment explaining the purpose of this validation.As suggested in the PR comments, it would be helpful to add a comment explaining the purpose of this validation, especially regarding the "inconsistent-indent-for-postings" case. This will improve the maintainability of the test suite.
Here's a suggested comment to add at the beginning of the file:
[ // This validation ensures that the number of postings is correct (4) // even when there are inconsistent indentations in the input. { "uri": "/api/journals", // ... (rest of the existing code) } ]integration-tests/space-of-posting-uint-can-be-empty/validations.json (1)
6-7: Consider adding a comment explaining the validation ruleThe validation rule checks for exactly 3 postings in the first record. While this is likely intentional, it might be helpful to add a comment explaining why specifically 3 postings are expected. This would improve maintainability and clarity for other developers.
Consider adding a comment like this:
"validations": [ [ "$.data.records[0].postings.length()", 3, "Ensure the first journal entry has exactly 3 postings" ] ]integration-tests/space-of-posting-uint-can-be-empty/main.bean (2)
3-5: Consider using a more recent date for account openings.The accounts "Assets:BankCard" and "Expenses:Food" are correctly opened with CNY as the currency. However, the date 1970-01-01 is typically used as a default in computing (Unix epoch) and may not be the most appropriate for financial records.
Consider using a more recent and relevant date for opening these accounts, such as the current year or when you actually started tracking these accounts.
1-10: Clarify the test's purpose and enhance its focus.The filename suggests this is an integration test for handling spaces in posting units, but the current content doesn't explicitly test this scenario. To improve the test:
- Add comments explaining the test's purpose.
- Include examples with and without spaces in posting units to demonstrate the behavior being tested.
- Consider adding assertions or expected outcomes to validate the test results.
Example addition to test space handling:
2023-12-07 "Space Test" "Testing space handling in posting units" Expenses:Food -100.00 CNY Expenses:Food -100.00CNY Assets:BankCard 200.00 CNYWould you like assistance in refining this test file to better focus on its intended purpose?
integration-tests/space-of-posting-uint-can-be-empty/main.zhang (1)
3-5: LGTM: Accounts properly opened.The Assets:BankCard and Expenses:Food accounts are correctly opened with CNY as the currency, consistent with the operating currency setting.
Consider adding a comment explaining the use of 1970-01-01 as the opening date, especially if this is a convention used throughout your tests. For example:
; Use Unix epoch as the default opening date for test accounts 1970-01-01 open Assets:BankCard CNYintegration-tests/inconsistent-indent-for-postings/main.zhang (2)
7-11: LGTM: Transaction structure suitable for testing inconsistent indentation.The transaction is correctly formatted for date and description. The inconsistent indentation and duplication of postings with varying indents appear intentional, serving the purpose of this test case for handling inconsistent posting indents.
However, for clarity, consider adding a comment explaining the purpose of this test case, as suggested in the PR comments.
Would you like me to provide a sample comment to explain the test case purpose?
1-11: Overall: Well-structured test case for inconsistent posting indentation.This file effectively serves its purpose as a test case for handling inconsistent indentation in postings. The configuration, account openings, and transaction entries are all correctly formatted for their intended use in this context.
To enhance clarity for future developers, consider adding a comment at the beginning of the file explaining the purpose of this test case, such as:
; Test case for handling inconsistent indentation in postings ; This file intentionally uses varying indents to ensure proper parsingThis addition would align with the suggestion made in the PR comments and improve the test case's documentation.
integration-tests/comments-between-postings/main.bean (1)
3-5: Consider using a more meaningful account opening date.The accounts "Assets:BankCard" and "Expenses:Food" are correctly opened with CNY as the currency. However, the opening date (1970-01-01) seems to be a placeholder. Consider using a more meaningful date, such as the actual date when these accounts were created or the start of the fiscal year.
integration-tests/comments-between-postings/main.zhang (3)
1-5: LGTM! Consider clarifying the account opening date.The operating currency and account setup look good. However, the account opening date (1970-01-01) seems unusual. If this is intentional for testing purposes, consider adding a comment to explain the rationale.
7-27: LGTM! Consider adding balance assertions.The transaction entries are well-structured and consistent. The varying placement of comments effectively tests different scenarios. To enhance the test case, consider adding balance assertions after the transactions to verify the final account balances.
Example of a balance assertion:
2023-12-06 balance Assets:BankCard -200 CNY 2023-12-06 balance Expenses:Food 200 CNY
1-27: Consider adding a file-level comment.To improve clarity, consider adding a comment at the beginning of the file explaining its purpose as a test case for handling comments in different positions within transactions. This would help other developers understand the intent of this file more quickly.
Example:
; Test case for handling comments in various positions within transactions ; This file tests the parser's ability to correctly process comments ; placed in different locations relative to transaction entries..github/workflows/release.yml (1)
127-127: Remove trailing space for consistency.There's a trailing space at the end of line 127. While this doesn't affect functionality, it's good practice to maintain consistent formatting.
Please remove the trailing space from this line:
- +🧰 Tools
🪛 yamllint
[error] 127-127: trailing spaces
(trailing-spaces)
zhang-core/src/data_type/text/exporter.rs (3)
112-112: Implement cost and price handling in postingsThe
// todo cost and pricecomment indicates that the implementation for exporting cost and price in postings is incomplete.Would you like assistance in implementing the cost and price handling in the
exportmethod forPosting? I can help provide the necessary code or open a GitHub issue to track this task.
Line range hint
114-121: Renamevec1to enhance code readabilityThe variable name
vec1is not descriptive of its purpose. Renaming it to something more meaningful, such aspartsorcomponents, would improve the readability and maintainability of the code.Consider changing the variable name:
-let vec1 = vec![ +let parts = vec![
545-545: Ensure correct indentation for transaction metadata in test caseIn the test case, the metadata line
a: bshould be indented appropriately. According to Beancount syntax, transaction-level metadata should be indented consistently with the postings to reflect the correct hierarchical structure.Please adjust the indentation to ensure consistency and correctness in the test case.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (19)
- .github/workflows/build-latest.yml (1 hunks)
- .github/workflows/release.yml (1 hunks)
- extensions/beancount/src/beancount.pest (1 hunks)
- extensions/beancount/src/parser.rs (2 hunks)
- integration-tests/comments-between-postings/main.bean (1 hunks)
- integration-tests/comments-between-postings/main.zhang (1 hunks)
- integration-tests/comments-between-postings/validations.json (1 hunks)
- integration-tests/inconsistent-indent-for-postings/main.bean (1 hunks)
- integration-tests/inconsistent-indent-for-postings/main.zhang (1 hunks)
- integration-tests/inconsistent-indent-for-postings/validations.json (1 hunks)
- integration-tests/space-of-posting-uint-can-be-empty/main.bean (1 hunks)
- integration-tests/space-of-posting-uint-can-be-empty/main.zhang (1 hunks)
- integration-tests/space-of-posting-uint-can-be-empty/validations.json (1 hunks)
- zhang-ast/src/data.rs (0 hunks)
- zhang-core/src/data_type/text/exporter.rs (4 hunks)
- zhang-core/src/data_type/text/parser.rs (2 hunks)
- zhang-core/src/data_type/text/zhang.pest (2 hunks)
- zhang-core/src/process/balance.rs (0 hunks)
- zhang-server/src/routes/transaction.rs (0 hunks)
💤 Files with no reviewable changes (3)
- zhang-ast/src/data.rs
- zhang-core/src/process/balance.rs
- zhang-server/src/routes/transaction.rs
🧰 Additional context used
🪛 yamllint
.github/workflows/release.yml
[error] 127-127: trailing spaces
(trailing-spaces)
🔇 Additional comments (32)
integration-tests/inconsistent-indent-for-postings/validations.json (1)
1-11: LGTM! The validation structure looks good.The JSON structure is valid, and the validation rule is well-formed. It correctly targets the
/api/journalsendpoint and checks for the expected number of postings in the first record.integration-tests/space-of-posting-uint-can-be-empty/validations.json (2)
1-11: LGTM: Well-structured validation file for API response testingThe file is well-structured and serves a clear purpose in validating API responses for the
/api/journalsendpoint. This aligns with the PR objectives of addressing inconsistencies in postings.
1-11: Verify alignment between file name and validation contentThe file name suggests that this test is for cases where the space in posting unit can be empty. However, the current validation only checks the number of postings, not their format or content. Could you please verify if:
- The file name accurately reflects the purpose of this validation, or
- Additional validations are needed to check for empty spaces in posting units?
This will ensure that the test coverage aligns with the intended functionality.
integration-tests/space-of-posting-uint-can-be-empty/main.bean (2)
1-1: LGTM: Operating currency correctly set.The operating currency is properly configured to CNY (Chinese Yuan). This is a good practice in Beancount files to define the primary currency for the ledger.
7-10:⚠️ Potential issueReview and adjust transaction details for consistency and completeness.
The transaction is structured correctly, but there are several points to consider:
- The account "Expenses:A" is inconsistent with "Expenses:Food". Consider unifying the account names.
- The transaction amounts (0.1 CNY) are unusually small. Verify if these are intended test values or if they should be more realistic.
- The balancing entry (likely from Assets:BankCard) is missing. Add this to ensure the transaction is balanced.
- The currency conversion rates (1 CNY = 1 USD) may not be realistic. Consider using more representative exchange rates if this is meant to mimic real transactions.
Here's a suggested revision:
2023-12-06 "KFC" "VME50 Package" Expenses:Food -50.00 CNY Expenses:Food -20.00 CNY @ 0.14 USD Expenses:Food -30.00 CNY @@ 4.20 USD Assets:BankCard 100.00 CNYTo verify the usage of these accounts and currencies in other files, you can run:
integration-tests/space-of-posting-uint-can-be-empty/main.zhang (2)
1-1: LGTM: Operating currency correctly set.The operating currency is properly configured to CNY, which is essential for this test case.
7-10: 🛠️ Refactor suggestionReview transaction entry and consider potential improvements.
The transaction entry demonstrates various posting formats, which is good for testing purposes. However, there are a few points to consider:
- The account "Expenses:A" is used, but it wasn't opened earlier. Consider using "Expenses:Food" consistently or opening the "Expenses:A" account.
- The transaction is not balanced. If this is intentional for testing error handling, consider adding a comment to explain this.
- The amounts are very small (-0.1CNY). If this is for testing precision, it might be worth adding a comment to explain the intention.
To ensure consistency in account usage across the codebase, let's verify the usage of "Expenses:A":
Consider adding comments to explain the purpose of each posting format:
2023-12-06 "KFC" "VME50 Package" ; Simple posting in operating currency Expenses:Food -0.1CNY ; Posting with explicit price Expenses:Food -0.1CNY@1USD ; Posting with total price Expenses:Food -0.1CNY@@1USDintegration-tests/inconsistent-indent-for-postings/main.bean (3)
1-5: LGTM: Currency option and account openings are correctly formatted.The operating currency is properly set, and the accounts are opened with the correct syntax. The spacing and indentation in this section are consistent.
7-7: LGTM: Transaction header is correctly formatted.The transaction date, status (completed), payee, and narration are properly formatted with consistent spacing.
1-11: Summary: Inconsistencies addressed, but further validation recommended.This review has addressed the main objectives of the PR by fixing inconsistent spacing in postings and removing unnecessary lines. However, to ensure the integrity of the Beancount file, I recommend the following additional steps:
- Verify that the transaction is correctly balanced after removing the duplicate postings.
- Consider adding a comment explaining the purpose of this file, especially if it's being used for testing inconsistent indentation scenarios.
- Run the Beancount parser on the modified file to ensure it's free of syntax errors.
To validate the Beancount file syntax, you can run the following command:
This will help ensure that the file is valid and can be properly parsed by Beancount tools.
integration-tests/inconsistent-indent-for-postings/main.zhang (2)
1-1: LGTM: Operating currency correctly set.The operating currency is properly configured to CNY (Chinese Yuan).
3-5: LGTM: Accounts properly opened.The Assets:BankCard and Expenses:Food accounts are correctly opened with CNY currency. The use of 1970-01-01 as the opening date is acceptable for test purposes.
integration-tests/comments-between-postings/validations.json (2)
1-23: LGTM! The validation structure is well-defined and consistent.The JSON structure for API response validations is clear and well-organized. It correctly defines validation rules for the
/api/journalsendpoint, ensuring that the first four records in the response data contain exactly two postings each.
1-23: Verify consistency of validation rules across the codebase.To ensure that these validation rules are consistent with the rest of the codebase and that the
/api/journalsendpoint behaves as expected, it would be beneficial to verify the following:
- The structure of the API response matches these validation rules.
- Other parts of the codebase that interact with journal postings expect two postings per record.
- There are no conflicting validation rules for the same endpoint in other test files.
To assist with this verification, you can run the following script:
This script will help identify other relevant parts of the codebase for manual review to ensure consistency.
✅ Verification successful
Validation rules for
/api/journalsare consistent across the codebase.All identified validation files enforce a
postings.length()of 2, and the corresponding code handling these postings aligns with these rules. No conflicting validation rules were found in other test files.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify consistency of validation rules and API structure # Test 1: Check for other validation files for the same endpoint echo "Checking for other validation files for /api/journals:" rg -l --type json '"uri":\s*"/api/journals"' integration-tests # Test 2: Search for code that handles journal postings echo "Searching for code that handles journal postings:" rg --type rust 'fn.*postings' src # Test 3: Look for API response structure definitions echo "Searching for API response structure definitions:" rg --type rust 'struct.*Journal' srcLength of output: 1071
Script:
#!/bin/bash # Description: Identify source code directories and search for functions handling journal postings # Test 4: Find potential source code directories echo "Finding potential source code directories:" fd --type d | rg 'src|lib|app|backend|server' # Note: Replace <identified_dir> with the actual directory name found from Test 4 results. # Test 5: Search for code that handles journal postings in the identified directory echo "Searching for code that handles journal postings in <identified_dir>:" rg --type rust 'fn.*postings' <identified_dir> # Test 6: Look for API response structure definitions in the identified directory echo "Searching for API response structure definitions in <identified_dir>:" rg --type rust 'struct.*Journal' <identified_dir>Length of output: 1757
Script:
#!/bin/bash # Description: Identify source code directories and search for functions handling journal postings # Test 4: Find potential source code directories echo "Finding potential source code directories:" SOURCE_DIRS=$(fd --type d | rg 'src|lib|app|backend|server') echo "$SOURCE_DIRS" # Convert the list of directories into an array IFS=$'\n' read -rd '' -a dirs <<<"$SOURCE_DIRS" # Iterate over each directory to search for journal postings functions for dir in "${dirs[@]}"; do echo "Searching for code that handles journal postings in $dir:" rg --type rust 'fn.*postings' "$dir" done # Iterate over each directory to search for API response structure definitions for dir in "${dirs[@]}"; do echo "Searching for API response structure definitions in $dir:" rg --type rust 'struct.*Journal' "$dir" doneLength of output: 29977
integration-tests/comments-between-postings/main.bean (3)
1-1: LGTM: Operating currency correctly set.The operating currency is properly set to CNY (Chinese Yuan). This is a good practice in Beancount files to define the primary currency for the ledger.
7-27: LGTM: Transactions correctly structured for testing comment placements.The transactions are correctly structured and balanced. The repetition of identical transactions with varying comment placements aligns with the file's purpose of testing "comments-between-postings". This setup effectively tests different scenarios for comment positioning within transaction entries.
1-27: Well-structured test file for comment handling in transactions.This Beancount file is well-structured and serves its purpose as a test case for handling comments in different positions within transactions. It correctly sets up the operating currency, opens necessary accounts, and provides multiple scenarios for comment placement in otherwise identical transactions.
The only suggestion for improvement is to consider using a more meaningful date for account openings instead of the placeholder date (1970-01-01).
Overall, this file effectively tests the parser's ability to handle comments in various positions within transaction entries.
.github/workflows/build-latest.yml (1)
71-73: Approve implementation, but clarification needed on Python's role.The addition of Python setup using
actions/setup-python@v5is implemented correctly. However, the purpose of adding Python to this workflow is not immediately clear from the context.
- Could you please clarify why Python 3.10 is now required in the test job?
- Consider adding a comment above this step to explain its purpose, which will help with future maintenance.
To ensure this change doesn't introduce any unintended side effects, let's verify if Python is used in any of the test commands:
✅ Verification successful
[/run_scripts]
Remove unnecessary Python setup step.
The
actions/setup-python@v5step is included in the workflow, but no Python commands are found in the test jobs. If Python is not required for the testing process, please consider removing this step to streamline the workflow.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check if Python is used in any test commands within the workflow # Test: Search for Python usage in test commands rg --type yaml 'run:.*python' .github/workflows/build-latest.ymlLength of output: 66
Script:
#!/bin/bash # Description: Perform a case-insensitive search for 'python' usage in the workflow file rg --ignore-case 'python' .github/workflows/build-latest.ymlLength of output: 131
.github/workflows/release.yml (2)
124-127: Approve Python setup, but clarification needed.The addition of Python 3.10 setup is good for consistency and ensures its availability for the build process. However, it's not immediately clear why Python is needed in this job.
Could you please clarify the purpose of adding Python to this workflow? This will help future maintainers understand the requirement. Consider adding a comment in the YAML file explaining the need for Python in this context.
🧰 Tools
🪛 yamllint
[error] 127-127: trailing spaces
(trailing-spaces)
Line range hint
180-181: Approve the updated job condition.The modification to the
docker-image-releasejob condition is a good improvement. It now runs for both tagged releases and pushes to the default branch, which aligns with best practices for continuous deployment.🧰 Tools
🪛 yamllint
[error] 127-127: trailing spaces
(trailing-spaces)
extensions/beancount/src/beancount.pest (5)
49-49: Optional whitespace aroundcommodity_nameinposting_amountThe change to allow optional whitespace around
commodity_nameinposting_amountincreases flexibility in parsing. This is beneficial for accommodating varied input formats.
50-50: Verify the optional components inposting_metaThe updated
posting_metarule includes multiple optional components with the use of?and*operators. Ensure that the combination of these operators does not lead to ambiguous parsing or unintended matches.
55-55: Consistency in allowing optional whitespace aroundcommodity_nameSimilar to
posting_amount, theposting_costrule now allows optional whitespace aroundcommodity_name. This improves consistency and flexibility in the grammar.
59-60: Optional whitespace inposting_single_priceandposting_total_priceAllowing optional whitespace around
commodity_namein these rules enhances the parser's ability to handle different formatting styles.
64-64: Simplification ofmetasruleBy redefining
metasto{ key_value_lines }, the grammar becomes cleaner and more maintainable. This change removes unnecessary complexity.zhang-core/src/data_type/text/exporter.rs (1)
98-98: LGTM!The change from
flat_maptomapin processingself.postingsis appropriate sinceposting.export()now returns aStringinstead of aVec<String>. This change simplifies the code and ensures that postings are handled correctly.extensions/beancount/src/parser.rs (2)
278-281: Transaction posting patterns updated correctlyThe pattern matching in the
transaction_postingfunction has been updated to remove themetafield, simplifying the return type. The new patterns correctly handle the combinations offlag,account_name, andposting_unit.
284-284: Variable unpacking aligns with new return structureThe unpacking of
retinto(flag, account, unit)reflects the updated return value from the pattern matching, ensuring thatmetais no longer expected.zhang-core/src/data_type/text/parser.rs (2)
321-321: Confirm handling of standalone valuable comments intransaction_lineThe addition of
[valuable_comment(_)] => (None, None),intransaction_lineallows for valuable comments that are not associated with postings or metadata. Ensure that this change is intentional and that such comments are properly processed in subsequent logic.
287-290:⚠️ Potential issueEnsure metadata handling is preserved after changes in
transaction_postingThe
transaction_postingfunction no longer returnsmeta, which may lead to loss of metadata associated with postings. Please verify that any necessary metadata is correctly parsed and stored elsewhere to prevent potential data loss.Also applies to: 293-293
⛔ Skipped due to learnings
Learnt from: Kilerd PR: zhang-accounting/zhang#382 File: zhang-core/src/data_type/text/parser.rs:351-365 Timestamp: 2024-10-18T07:09:39.818Z Learning: In the function `tags_or_links` in `zhang-core/src/data_type/text/parser.rs`, unexpected node types can be safely ignored without returning an error.zhang-core/src/data_type/text/zhang.pest (2)
62-62: Simplification of 'metas' Rule May Affect Metadata ParsingThe
metasrule has been simplified from:metas = { indentation_push ~ key_value_lines ~ DROP }to:
metas = { key_value_lines }Removing
indentation_pushandDROPmight impact how indentation is handled within metadata, potentially causing parsing inconsistencies.Please verify that this change does not introduce parsing issues with metadata. Consider running existing test cases or adding new ones to ensure metadata is parsed correctly.
28-28: Ensure All References to 'transaction_detail' Are UpdatedThe
transactionrule now referencestransaction_linesinstead oftransaction_detail:-transaction = { date ~ transaction_flag? ~ (space+ ~ quote_string){0, 2} ~ tags_or_links? ~ space* ~ comment? ~ transaction_detail } +transaction = { date ~ transaction_flag? ~ (space+ ~ quote_string){0, 2} ~ tags_or_links? ~ space* ~ comment? ~ transaction_lines }Ensure that all other references to
transaction_detailin the grammar and associated code are updated totransaction_linesto prevent unresolved references.Run the following script to check for any remaining instances of
transaction_detail:This will help confirm that the rename is fully applied throughout the codebase.
✅ Verification successful
All references to 'transaction_detail' have been successfully updated to 'transaction_lines'.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Search for occurrences of 'transaction_detail' in the codebase. # Test: Find any instances of 'transaction_detail'. Expect: No matches returned. rg 'transaction_detail'Length of output: 23
Script:
#!/bin/bash # Description: Thoroughly search for any remaining references to 'transaction_detail' in the codebase. # Test: Ensure no instances of 'transaction_detail' exist in variable names, function declarations, or comments. # Search for 'transaction_detail' in code identifiers using ast-grep ast-grep --lang pest --pattern $'$_ = transaction_detail' || true ast-grep --lang pest --pattern $'function $_($$...) { $$$ transaction_detail $$$ }' || true # Additionally, use ripgrep with context to find 'transaction_detail' references rg 'transaction_detail\s*=' rg '\btransaction_detail\b'Length of output: 435
Script:
#!/bin/bash # Description: Thoroughly search for any remaining references to 'transaction_detail' in the codebase. # Test: Ensure no instances of 'transaction_detail' exist in variable names, function declarations, or comments. # Search for 'transaction_detail' in assignments and declarations rg 'transaction_detail\s*=' rg 'let\s+transaction_detail\b' rg 'const\s+transaction_detail\b' rg 'var\s+transaction_detail\b' # Search for 'transaction_detail' in function calls rg '\btransaction_detail\(' # Search for 'transaction_detail' in comments rg '#.*transaction_detail' rg '//.*transaction_detail' rg '/\*.*transaction_detail.*\*/' # Additionally, use fd to find relevant files and search within them fd -e pest -e js -e ts -e py | xargs rg 'transaction_detail'Length of output: 319
Kilerd
deleted the
381-cannot-parse-comment-lines-betwen-actual-postings
branch
Summary by CodeRabbit
New Features
Bug Fixes
Documentation
Tests