214 lines
7 KiB
Text
214 lines
7 KiB
Text
--ISSUE
|
|
Content-Type: application/issue
|
|
|
|
ID: 1
|
|
Type: feature
|
|
Title: string formatting utilities
|
|
Status: in-progress
|
|
Priority: high
|
|
Created: 2025-05-01
|
|
Relationships:
|
|
Description: implement utilities for formatting strings. The formatting should
|
|
be inspired by Python 3K PEP 3101 in addition to their standard
|
|
library utilities starting from ver. 3.7. Optimizations should
|
|
focus on V8 support.
|
|
|
|
--ISSUE
|
|
Content-Type: application/issue
|
|
|
|
ID: 2
|
|
Type: feature
|
|
Title: describe development workflow in CONTRIBUTING.md
|
|
Status: open
|
|
Priority: medium
|
|
Created: 2025-05-01
|
|
Relationships:
|
|
Description: It's a good idea to describe the development workflow, including
|
|
branching strategies earlier on, so that if someone is interested
|
|
in forking, they can pick up right away. It's not meant for
|
|
contributions though. I'm currently not interested in external
|
|
contributions.
|
|
|
|
--ISSUE
|
|
Content-Type: application/issue
|
|
|
|
ID: 3
|
|
Type: bugfix
|
|
Title: modularize testing further
|
|
Status: done
|
|
Priority: high
|
|
Created: 2025-05-01
|
|
Relationships:
|
|
Description: Since I am going to implement unit tests as well as integration
|
|
tests and probably some benchmarks, it makes sense to introduce
|
|
another sub-level directory for each type of test, say
|
|
tests/unit/, tests/integration, etc.
|
|
|
|
--ISSUE
|
|
Content-Type: application/issue
|
|
|
|
ID: 4
|
|
Type: feature
|
|
Title: migrate testing framework from Jest to Mocha
|
|
Status: in-progress
|
|
Priority: high
|
|
Created: 2025-05-01
|
|
Relationships:
|
|
Description: I really don't like behavior-driven testing, at least when it comes
|
|
to unit testing. It feels like Walldorf education... Where I need
|
|
to come up with an abstraction for describing my test. A function
|
|
has an input and gives an output. That's what I want to test. I'm
|
|
not trying to find the philosophical meaning of my functions...
|
|
Hopefully Mocha is the savior. I'm sticking to xUnit based testing
|
|
from now on.
|
|
|
|
--ISSUE
|
|
Content-Type: application/issue
|
|
|
|
ID: 5
|
|
Type: bugfix
|
|
Title: fix critical bugs across core modules
|
|
Status: done
|
|
Priority: high
|
|
Created: 2026-03-13
|
|
Relationships:
|
|
Description: multiple logic bugs prevent the library from functioning.
|
|
manager.ts getLogger() has an inverted type check and missing
|
|
return statement. config.ts basicConfig() assigns wrong option
|
|
fields (filemode instead of datefmt/style) and has unreachable
|
|
conditions. logger.ts isEnabledFor() always caches false,
|
|
_log() never calls handle(), and makeRecord() uses .keys()
|
|
instead of Object.keys(). handler.ts format() has no return
|
|
statement and is missing a formatter getter.
|
|
|
|
--ISSUE
|
|
Content-Type: application/issue
|
|
|
|
ID: 6
|
|
Type: feature
|
|
Title: implement remaining Logger level methods
|
|
Status: done
|
|
Priority: high
|
|
Created: 2026-03-13
|
|
Relationships: dependsOn:5
|
|
Description: Logger only implements debug(). The info(), warning(), error(),
|
|
and critical() methods are missing entirely. The _log() method
|
|
also needs to be completed so it actually calls handle() after
|
|
creating the LogRecord.
|
|
|
|
--ISSUE
|
|
Content-Type: application/issue
|
|
|
|
ID: 7
|
|
Type: feature
|
|
Title: implement Formatter subsystem
|
|
Status: done
|
|
Priority: high
|
|
Created: 2026-03-13
|
|
Relationships: dependsOn:1
|
|
Description: the three core Formatter methods are stubs returning placeholder
|
|
strings. PercentFormatterStyle._format() needs to perform actual
|
|
%-style field substitution against LogRecord attributes.
|
|
Formatter.formatTime() needs a JS Date/Intl-based implementation
|
|
replacing the Python time.strftime references.
|
|
Formatter.formatError() needs to format Error.stack into a
|
|
string. The datetime helper module is empty and needs time
|
|
formatting utilities.
|
|
|
|
--ISSUE
|
|
Content-Type: application/issue
|
|
|
|
ID: 8
|
|
Type: feature
|
|
Title: implement browser-compatible Handler output
|
|
Status: done
|
|
Priority: high
|
|
Created: 2026-03-13
|
|
Relationships: dependsOn:5
|
|
Description: StreamHandler has no emit() implementation and its constructor
|
|
ignores the stream parameter. The helper/stream module is a
|
|
stub that needs a browser-compatible Writable interface backed
|
|
by console output. FileHandler should be dropped or gated behind
|
|
a Node.js environment check since browser environments have no
|
|
filesystem write access. A ConsoleHandler targeting the browser
|
|
console API (console.log/warn/error by level) is the primary
|
|
output target.
|
|
|
|
--ISSUE
|
|
Content-Type: application/issue
|
|
|
|
ID: 9
|
|
Type: feature
|
|
Title: implement Manager logger hierarchy
|
|
Status: done
|
|
Priority: high
|
|
Created: 2026-03-13
|
|
Relationships: dependsOn:5
|
|
Description: Manager.getLogger() does not establish parent-child
|
|
relationships between loggers based on dot-separated names.
|
|
The Placeholder fixup logic is incomplete. Logger propagation
|
|
depends on this hierarchy being correctly built so that child
|
|
loggers forward records to parent handlers.
|
|
|
|
--ISSUE
|
|
Content-Type: application/issue
|
|
|
|
ID: 10
|
|
Type: feature
|
|
Title: add documentation
|
|
Status: done
|
|
Priority: medium
|
|
Created: 2026-03-13
|
|
Relationships:
|
|
Description: write user-facing documentation covering module usage, API
|
|
reference, and configuration. The docs/ directory has stubs
|
|
(README.md, logging-cookbook.md) that need to be fleshed out.
|
|
TypeDoc generates API docs from source but a prose guide with
|
|
examples is needed for onboarding.
|
|
|
|
--ISSUE
|
|
Content-Type: application/issue
|
|
|
|
ID: 11
|
|
Type: feature
|
|
Title: add support for asynchronous calls
|
|
Status: open
|
|
Priority: low
|
|
Created: 2026-03-13
|
|
Relationships:
|
|
Description: introduce async-aware logging so that handlers which perform
|
|
I/O (e.g. network, storage) do not block the caller. This may
|
|
involve an AsyncHandler base class or async emit() overloads,
|
|
and consideration of how log record ordering is preserved
|
|
across concurrent async contexts.
|
|
|
|
--ISSUE
|
|
Content-Type: application/issue
|
|
|
|
ID: 12
|
|
Type: feature
|
|
Title: implement OCSF formatter
|
|
Status: open
|
|
Priority: low
|
|
Created: 2026-03-13
|
|
Relationships:
|
|
Description: implement a Formatter subclass that outputs log records in
|
|
Open Cybersecurity Schema Framework (OCSF) format. This
|
|
enables structured security event logging compatible with
|
|
SIEM systems and security analytics tooling.
|
|
|
|
--ISSUE
|
|
Content-Type: application/issue
|
|
|
|
ID: 13
|
|
Type: feature
|
|
Title: implement browser local storage handler
|
|
Status: done
|
|
Priority: medium
|
|
Created: 2026-03-13
|
|
Relationships: dependsOn:8
|
|
Description: implement a Handler subclass that persists log records to
|
|
browser localStorage or IndexedDB as a replacement for
|
|
FileHandler in browser environments. Should support log
|
|
rotation by size or entry count to avoid exceeding storage
|
|
quotas.
|