JCN-518: Actualizar README para sacar nota de doble wildcard#29
JCN-518: Actualizar README para sacar nota de doble wildcard#29jormaechea merged 1 commit intomasterfrom
Conversation
📝 WalkthroughWalkthroughThe documentation and related test for excluding fields from logs were updated to demonstrate and verify the exclusion of a different nested field using wildcard patterns. The example now focuses on excluding the Changes
Sequence Diagram(s)sequenceDiagram
participant Model
participant Logger
Model->>Logger: Prepare data for logging
Logger->>Logger: Exclude fields matching patterns (e.g., *.preferences.**.specialNotes)
Logger-->>Model: Return sanitized log data
Possibly related PRs
Suggested labels
Poem
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ast-grep (0.38.1)tests/model.jsThanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 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 (
|
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
README.md (1)
843-843: Fix markdown formatting issues.The static analysis tool has flagged hard tabs in the markdown file. Please replace the hard tabs with spaces for consistent formatting.
- <summary>You can exclude fields for logs in case you have sensitive information in your entries such as passwords, secondFactor, etc.</summary> + <summary>You can exclude fields for logs in case you have sensitive information in your entries such as passwords, secondFactor, etc.</summary> - 'preferences.**.specialNotes', // Exclude the specialNotes field without knowing the intermediate field path between such field and the root path + 'preferences.**.specialNotes', // Exclude the specialNotes field without knowing the intermediate field path between such field and the root path - preferences: { - shippingDetails: { - specialNotes: 'some shipping notes' - } - } + preferences: { + shippingDetails: { + specialNotes: 'some shipping notes' + } + } - preferences: { - shippingDetails: {} - } - location: { - country: 'some-country', - address: 'some-address' + preferences: { + shippingDetails: {} + } + location: { + country: 'some-country', + address: 'some-address'Also applies to: 852-852, 866-870, 906-912
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
README.md(6 hunks)tests/model.js(2 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
`**/*.js`: Never report errors of the following categories `lint/suspicious/noRe...
**/*.js: Never report errors of the following categorieslint/suspicious/noRedundantUseStrict,lint/complexity/noThisInStatic,lint/complexity/noStaticOnlyClass, reported by Biome.
⚙️ Source: CodeRabbit Configuration File
List of files the instruction was applied to:
tests/model.js
🧠 Learnings (2)
README.md (1)
Learnt from: lautaro-echeverria
PR: janis-commerce/model#28
File: lib/helpers/log.js:33-36
Timestamp: 2025-05-13T18:17:19.791Z
Learning: In the @janiscommerce/model package, the `omitRecursive` function in `lib/helpers/utils.js` expects an array of string patterns as its second parameter. If a non-array value is passed, it will return a clone of the original object without excluding any fields.
tests/model.js (1)
Learnt from: lautaro-echeverria
PR: janis-commerce/model#28
File: lib/helpers/log.js:33-36
Timestamp: 2025-05-13T18:17:19.791Z
Learning: In the @janiscommerce/model package, the `omitRecursive` function in `lib/helpers/utils.js` expects an array of string patterns as its second parameter. If a non-array value is passed, it will return a clone of the original object without excluding any fields.
🪛 markdownlint-cli2 (0.17.2)
README.md
843-843: Hard tabs
Column: 1
(MD010, no-hard-tabs)
852-852: Hard tabs
Column: 1
(MD010, no-hard-tabs)
866-866: Hard tabs
Column: 1
(MD010, no-hard-tabs)
867-867: Hard tabs
Column: 1
(MD010, no-hard-tabs)
868-868: Hard tabs
Column: 1
(MD010, no-hard-tabs)
869-869: Hard tabs
Column: 1
(MD010, no-hard-tabs)
870-870: Hard tabs
Column: 1
(MD010, no-hard-tabs)
906-906: Hard tabs
Column: 1
(MD010, no-hard-tabs)
907-907: Hard tabs
Column: 1
(MD010, no-hard-tabs)
908-908: Hard tabs
Column: 1
(MD010, no-hard-tabs)
909-909: Hard tabs
Column: 1
(MD010, no-hard-tabs)
910-910: Hard tabs
Column: 1
(MD010, no-hard-tabs)
911-911: Hard tabs
Column: 1
(MD010, no-hard-tabs)
🔇 Additional comments (8)
tests/model.js (3)
867-867: LGTM! Test exclusion pattern updated to match documentation.The change from
'**.address'to'*.preferences.**.specialNotes'correctly aligns the test with the updated README example, demonstrating proper double wildcard usage for excluding nested fields without knowing the complete intermediate path.
875-879: LGTM! Test data structure matches the new documentation example.The added
preferences.shippingDetails.specialNotesstructure is consistent with the updated exclusion pattern example in the README, ensuring the test validates the correct behavior.
888-894: LGTM! Expected output correctly reflects the new exclusion pattern.The expected logged output properly shows:
preferences.shippingDetailsbecomes an empty object{}(specialNotes excluded)location.addressremains in the output (no longer excluded)This validates that the field exclusion mechanism works as documented.
README.md (5)
161-161: LGTM! Link reference improvement.The updated link reference provides better navigation to the specific section about excluding fields from logs.
852-852: LGTM! Improved example demonstrates double wildcard usage more clearly.The change from
'**.address'to'preferences.**.specialNotes'provides a better example of when to use the double wildcard pattern - when you need to exclude a specific nested field without knowing the complete intermediate path structure.
866-870: LGTM! Example data structure supports the new exclusion pattern.The updated example data with
preferences.shippingDetails.specialNoteseffectively demonstrates the scenario where the double wildcard pattern is useful.
906-912: LGTM! Logged output example correctly shows the exclusion behavior.The updated example output clearly demonstrates that:
- The
specialNotesfield is excluded (empty object atpreferences.shippingDetails)- Other fields like
location.addressremain visible- The double wildcard pattern works as intended
936-936: LGTM! Clearer explanation of double wildcard usage.The updated note better explains that
**is used when the intermediate field path is unknown between the root and the target field.
Historia de usuario
https://janiscommerce.atlassian.net/browse/JCN-517
Sub-tarea
https://janiscommerce.atlassian.net/browse/JCN-518
Descripcion del requerimiento
Actualizar archivo README del paquete
@janiscommerce/modelpara generar confusiones redundantes sobre el uso del doble wildcard.Descripcion de la solucion
Summary by CodeRabbit
Documentation
Tests