asciidoctor / asciidoctor.js

:scroll: A JavaScript port of Asciidoctor, a modern implementation of AsciiDoc
https://asciidoctor.org
MIT License
720 stars 131 forks source link

Must LoggerSeverity (namespace) needed to be exposed? #1114

Open bitPogo opened 3 years ago

bitPogo commented 3 years ago

This question refers only to the types, not to the actual code, since the usage there is clear by the context.

ggrossetie commented 3 years ago

Are you saying that Asciidoctor.LoggerSeverity is not available/visible in TypeScript?

https://github.com/asciidoctor/asciidoctor.js/blob/3384a6bdab7addc8095aa0ff6fabd3cb2e276946/packages/core/types/index.d.ts#L394-L396

bitPogo commented 3 years ago

Nope...it should be useable, but I see no place where it is actually used.

ggrossetie commented 3 years ago

OK, I didn't know :smile:

I guess we could add a test in core/types/tests.ts. This API can be useful when you want to use a custom logger. You can learn more about that here: https://github.com/asciidoctor/asciidoctor.js/blob/cb0db00597ae7ecfd65cc717f3e67f8c284d5abe/docs/modules/processor/pages/logging-api.adoc#custom-logger

bitPogo commented 3 years ago

It's actually usage is only internal, since the namespace is not ported to the outside...at least not in typescript. However the code is speaking about it. The question is, if it should be exposed (so adding to the Asciidoctor class LoggerSeverity) or let it internal (so the type definition is dead code and should be delete, since it is basically just there).

bitPogo commented 3 years ago

Ah...so my first answer was wrong...Asciidoctor.LoggerSeverity is not present. Sorry a long day...I rewrote the whole types for kotlin...so thats why I stumbled over all those stuff...