fix(types): fix the types

[boneskull]

• I missed that the default export is actually an instance
• And that Loggerr is a property of that instance
• Also added more tests and reformatted

[boneskull]

@wesleytodd I notice that the levels option mostly appears to be an array of strings, but in the cli formatter, it's a mapping of level name to color. Can/should all formatters use both formats?

[wesleytodd]

Oops, sorry this got lost in the pile as I was traveling.

it's a mapping of level name to color. Can/should all formatters use both formats?

I think that was the only one doing that. The general idea was that someone could create their own formatter as long as the api was fmt(opts): (date, level, data) => string (pardon the likely wrong annotation, I hate my life)

So those options are defined by the formatter. I would type them individually and try to make clear the interface is open ended.

[boneskull]

@wesleytodd for my purposes (since I'm not making a formatter) I would choose to punt on the fact that the formatter has any impact on the options. I'll add a note about it.

[wesleytodd]

Sounds good to me.

[boneskull]

Sorry, I got nerd-sniped and actually implemented it. some of it.

[boneskull]

@wesleytodd This is ready IMO.

I ended up touching index.js just to tell TS to ignore it.

• A nice thing is now streams knows about levels and so will expect the arrays to be of equal length
• I didn't end up touching formatter-specific options
• Referencing a level by its number is now typesafe

[boneskull]

I should probably mention that since the types directly consume WritableStream from @types/node, including @types/node as a production dependency is best practice. I didn't want to do this because I am trying to not fuck with anything.

Failing that, I threw a directive in there that should cause compatible editors to automatically fetch @types/node if not present.

[wesleytodd]

I should probably mention that since the types directly consume WritableStream from @types/node, including @types/node as a production dependency is best practice.

And this is one of the things I think is fundamentally broken in the design of TS. But since folks dont seem to care about my opinions on this stuff, I would be fine if following the best practice for loud minority of users out there who might care as long as the quite majority also don't seem to mind (and I certainly don't mind the bloat, my projects are all fast already by avoiding these poorly done tools).

EDIT: so if you want to add that, go for it. I will not be publishing tonight anyway, but will try to in the morning.

[wesleytodd]

loggerr@4.2.0