eslint.config.js (1)

75-95: Test configuration registers the security plugin but omits the corresponding rule declarations.

In the main configuration (Lines 50–62), security rules are explicitly set to 'off' so that eslint-disable comments referencing them are recognized. The test configuration registers the plugin at Line 77 but does not mirror these 'off' declarations. Should any test file contain an eslint-disable comment for a security rule, it would trigger an "unknown rule" warning.

This is a minor concern — if no test files currently use such comments, it's a non-issue. But for consistency, one might consider aligning the two configurations.

src/__tests__/formatter.test.ts (1)

169-173: Minor observation: this test case does not disable emoji.

At Line 171, LogFormatter.format(LogLevel.INFO, 'Message', 'test string') is called without { includeEmoji: false }. The test still passes because it only asserts toContain('test string'), but the output will include an emoji segment (likely [ℹ️]). This appears intentional — verifying that emoji inclusion doesn't break string data formatting — but if consistency with other tests was the goal, one might add the option here as well.

src/formatter/emoji-data.ts (1)

98-100: The catch-all keywords may be rather... enthusiastic, if I may say so.

The keywords 'new' and 'improve'/'improved' in the catch-all sparkles mapping are quite generic. A log message like "New user session created" or "Improved cache hit ratio" would match ✨ rather than falling through to a level-based fallback, which may not always be the desired behaviour. Worth considering whether these broad terms belong in a catch-all or if they warrant narrower phrasing.

src/formatter/emoji-selector.ts (2)

186-221: The dual switch statements are rather thorough, though perhaps excessively so.

Both the custom fallback lookup (lines 190–204) and the default fallback lookup (lines 208–221) enumerate every level identically. Since levelName is already validated as a known level (the UNKNOWN case returns early at line 183), and FALLBACK_EMOJI is a typed Record, this could be condensed. However, I recognise this was likely a deliberate choice to satisfy the security/detect-object-injection ESLint rule by avoiding bracket notation. Entirely at your discretion.

♻️ Optional: Condensed fallback lookup using a local map

  private static getFallbackEmoji(level: LogLevel): string {
    const levelName = EmojiSelector.getLevelName(level);

    if (levelName === 'UNKNOWN') {
      return '';
    }

    const { customFallbacks = {} } = EmojiSelector.config;

-   // Check custom fallbacks first using safe property access
-   if (Object.prototype.hasOwnProperty.call(customFallbacks, levelName)) {
-     switch (levelName) {
-     case 'DEBUG':
-       return customFallbacks.DEBUG || '';
-     case 'INFO':
-       return customFallbacks.INFO || '';
-     case 'WARN':
-       return customFallbacks.WARN || '';
-     case 'ERROR':
-       return customFallbacks.ERROR || '';
-     case 'LOG':
-       return customFallbacks.LOG || '';
-     default:
-       return '';
-     }
-   }
-
-   // Use default fallback with explicit switch
-   switch (levelName) {
-   case 'DEBUG':
-     return FALLBACK_EMOJI.DEBUG;
-   case 'INFO':
-     return FALLBACK_EMOJI.INFO;
-   case 'WARN':
-     return FALLBACK_EMOJI.WARN;
-   case 'ERROR':
-     return FALLBACK_EMOJI.ERROR;
-   case 'LOG':
-     return FALLBACK_EMOJI.LOG;
-   default:
-     return '';
-   }
+   // Safe: levelName is one of the known literal types after UNKNOWN check
+   const levels = ['DEBUG', 'INFO', 'WARN', 'ERROR', 'LOG'] as const;
+   for (const l of levels) {
+     if (l === levelName) {
+       if (Object.prototype.hasOwnProperty.call(customFallbacks, l)) {
+         return customFallbacks[l] || '';
+       }
+       return FALLBACK_EMOJI[l];
+     }
+   }
+   return '';
  }

---

88-93: Minor observation: the 'i' flag is redundant with pre-lowercased input.

prepareSearchText (line 145) already lowercases the search text, yet the compiled regexes use the 'i' flag. Not harmful — merely a negligible redundancy. No action needed unless you wish to shave a micro-optimisation.

src/__tests__/emoji-integration.test.ts (1)

73-84: Minor style observation: trailing argument artifacts.

Lines 77–78 have a trailing undefined, with no subsequent argument before the closing parenthesis. This appears in several places (lines 90–92, 103–105, etc.) and suggests a parameter was removed during iteration. Syntactically valid, but a trifle untidy.

       const formatted = LogFormatter.format(
         LogLevel.INFO,
         'Deployed to production',
-        undefined,
-
+        undefined
       );

README.md (1)

411-611: Sir, I must commend the thoroughness of this new emoji documentation section.

The Context-Aware Emoji Support section is exceptionally well-structured, providing comprehensive examples, configuration options, and practical use cases. The documentation clearly demonstrates both basic and advanced usage patterns, which should prove invaluable to users integrating this feature.

However, I would suggest elevating the compatibility note currently positioned at Line 610 to a more prominent location, perhaps immediately following the Quick Start section around Line 447. Given that emoji are now enabled by default, existing users may benefit from understanding this behavioral change earlier in their reading journey, sir.