|
| 1 | +# higher prio |
| 2 | + |
1 | 3 | - `bunyan` (without redir) ^C should stop, doesn't since recent change
|
2 | 4 | - man page for the bunyan CLI (refer to it in the readme)
|
3 |
| -- `tail -f`-like support |
4 |
| -- 2.0 (?) with `v: 1` in log records. Fwd/bwd compat in `bunyan` CLI |
| 5 | + |
| 6 | + |
| 7 | +# changes to ctor and log.child to separate fields from config |
| 8 | + |
| 9 | +Current: |
| 10 | + createLogger(<config-and-fields>) |
| 11 | + log.child(<config-and-fields>, <just-fields-bool>) |
| 12 | + |
| 13 | +Could be: |
| 14 | + createLogger(<config-and-fields>, <fields>) |
| 15 | + log.child(<config-and-fields>, <fields>) |
| 16 | + # Still support: log.child(<config-and-fields>, <just-fields-bool>) |
| 17 | + |
| 18 | +Pros: Compat issues are minimal: a change is only required if there is a |
| 19 | +collision with used field and a new config var name. |
| 20 | +Cons: A *slight* con is that my guess is the common usage of child is |
| 21 | +`log.child(<fields>)`, so the more future-proof common usage becomes: |
| 22 | + log.child(null, <fields>) |
| 23 | +That's not too bad. It is clearer at least than: |
| 24 | + log.child(<fields>, true) |
| 25 | + |
| 26 | +TODO: |
| 27 | +- is there a ticket for this work already? |
| 28 | +- make the change |
| 29 | +- do a migration guide? i.e. provide the grep commands to find all |
| 30 | + possible calls to inspect. E.g. if don't have `rg logUndefined` in your |
| 31 | + code, then you are fine. And one time future-proofing via changing |
| 32 | + to fields in the *second* arg. |
| 33 | +- list of issues/pulls that wanted to add new config fields |
| 34 | + |
5 | 35 |
|
6 | 36 | # docs
|
7 | 37 |
|
|
10 | 40 |
|
11 | 41 | # someday/maybe
|
12 | 42 |
|
| 43 | +- 2.0 (?) with `v: 1` in log records. Fwd/bwd compat in `bunyan` CLI |
| 44 | +- `tail -f`-like support |
13 | 45 | - full-on docs
|
14 | 46 | - better examples/
|
15 | 47 | - better coloring
|
|
0 commit comments