chore: convert TODO to MIME TODO format and add issues 5-9
This commit is contained in:
Tiara Rodney
parent
25ec89c3b4
commit
04e9768e89
1 changed files with 100 additions and 53 deletions
153
TODO
153
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.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue