Added info(), warning(), error(), and critical() methods to Logger, each gated by isEnabledFor(). All level methods tested including effective level filtering.
151 lines
5.1 KiB
Text
151 lines
5.1 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: 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.
|