diff --git a/TODO b/TODO index ceb7fc8..345a13a 100644 --- a/TODO +++ b/TODO @@ -1,51 +1,5 @@ -# TODO List for esm-logging - -This is a poor-man's issue tracker. I am not primarily a GitHub user so don't -want to commit to their issue tracking feature, but my primary SVC service -provider (Bitbucket) only offers paid integration into their issue tracker -(Jira). I don't have the time (and patience) at the moment to analyze the best -approach, so this file will have to suffice. - -It's a very simple concept: Track any issues (features, bugfixes, hotfixes) in -here, assign a sequential number to it and use that number when branching. - -I will try to develop a format so that I can parse the file later on, should I -decide to migrate to a real issue tracker. It's probably going to be Bugzilla, -but for that my html-theme-ref project needs to stabilize first. - -## Format Specification - -The file uses Markdown conventions for formatting headers and other text block -entitities, but SHOULD NOT be considered a Markdown file. That's why it has no -definitive file extension. - -Each issue entry follows a structured format for easier parsing and future -migration. Issues MUST be **appended** to this file and never moved, to -preserve Git diffing. - -### Issue Format - -``` - -ID: [ISSUE-NUMBER] -Type: [feature/bugfix/hotfix] -Title: [Short title] -Status: [open/in-progress/done] -Priority: [low/medium/high] -Created: [YYYY-MM-DD] -Description: [Detailed explanation] - ---- -``` - -- ISSUE-NUMBERs must be sequential -- truncation of description must be indentended so that every line starts at the - same column -- issues must be started with two LF -- issues must be terminated with two LF, then `---` -- issues may have a free-text field (epilog), which must be started with two LF. - -## Issues +--ISSUE +Content-Type: application/issue ID: 1 Type: feature @@ -53,12 +7,14 @@ 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 @@ -66,13 +22,15 @@ 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 @@ -80,12 +38,14 @@ 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. + tests/unit/, tests/integration, etc. ---- +--ISSUE +Content-Type: application/issue ID: 4 Type: feature @@ -93,6 +53,7 @@ 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 @@ -101,4 +62,90 @@ Description: I really don't like behavior-driven testing, at least when it comes 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: open +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: open +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: open +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: open +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: open +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.