syntropylog 0.9.18 → 0.9.20

package/CHANGELOG.md

@@ -1,5 +1,25 @@
 # Changelog
 
+## 0.9.20
+
+### Patch Changes
+
+- Optimization and Security Refactor:
+  - Migrated configuration validation from Zod to Valibot to significantly reduce bundle size.
+  - Removed `ConcurrencyLimiter` and `logConcurrencyLimit` to simplify pipeline processing and eliminate async bottlenecks.
+  - Restored `optionalChalk` implementation for built-in visual console transports.
+  - Achieved 100% global test coverage.
+  - Implemented ReDoS (Catastrophic Backtracking) defenses in `MaskingEngine` with synchronous length limits on property keys.
+
+## 0.9.19
+
+### Patch Changes
+
+- **Shutdown and package size**
+  - **Shutdown:** `shutdown()` now resolves only after all shutdown logs are written. LifecycleManager reorders shutdown (Redis + external processes first), awaits final log calls, then closes the logger factory so no logs appear after "Shutdown completed".
+  - **Smaller bundles:** Main CJS/ESM bundles are minified with Terser (~176KB → ~60KB each). Build no longer publishes `tsconfig.tsbuildinfo`; `src/services` excluded from type build.
+  - **README:** Added "Tree-shaking friendly" section.
+
 ## 0.9.18
 
 ### Patch Changes

package/README.md

@@ -47,6 +47,10 @@ SyntropyLog was designed with the constraints of **banking, healthcare, and fina
 - **HIPAA**: Field-level control over what appears in logs at each severity level via the Logging Matrix.
 - **SOX**: Immutable audit trail via `withRetention` bindings and dedicated transports.
 
+### Tree-shaking friendly
+
+We ship with `sideEffects: false` and ESM so bundlers (Vite, Rollup, webpack, esbuild) can tree-shake unused code. What ends up in your app is only what you import.
+
 ---
 
 ## 🛡️ Why SyntropyLog? (The Resilience Factor)
@@ -443,7 +447,10 @@ await syntropyLog.init({
 
 > **Silent Observer guarantee**: if the masking engine fails for any reason, it returns the original object and the application keeps running — it never throws.
 
-**Performance**: Built-in rules use synchronous regex matching (safe, known patterns). Custom rules you add still use the timeout-protected `regex-test` worker to guard against ReDoS. This avoids the ~3–6s delay per log that occurred when every key was tested via the worker queue.
+**Performance**: Built-in rules use synchronous regex matching (safe, known patterns). Custom rules use the same synchronous engine for maximum speed.
+
+> ⚠️ **Security Warning (Custom Rules)**
+> Node.js regular expressions execute synchronously on the main thread. To prevent Event Loop blocking, SyntropyLog automatically skips evaluating any JSON keys longer than 256 characters. However, when writing **Custom Masking Rules**, it is your responsibility to write optimized, ReDoS-safe regular expressions. A catastrophic backtracking pattern in a custom rule could temporarily freeze your application if triggered by a specifically crafted payload.
 
 ---