Sergiy Yavorsky

@homer0 thanks for the feedback. You have a good point, it might be too late to fix anything now. It was my mistake blindly believing node/npm would transparently accept this...

Sorry for the late response. it does make sense, but what if someone is already relying on *.ts delivered with the package? Maybe, moving forward, the better option would be...

> The easiest way to find out for sure is to post an update, then check for incoming bug reports. nah, there were a couple of bad episodes when I...

On other hand, I am not completely sure this is something to be solved in comment-parser. Whoever uses it will do the bundling/tree-shaking/etc the way they need, unless it's some...

I see. It's arguable that 180kB improves the Build/CI time, but baking specific node/browser/es packages may still make sense for someone. I will put it on my stack.

Nah,sorry. But sounds like a good feature to have one day.

I believe you have already found [this example](https://syavorsky.github.io/comment-parser/#parse-advanced-parsing). It is not clear how to get tokenizers though as you pointed out CommonJS option ```js const {default: tag} = require('comment-parser/lib/parser/tokenizers/tag') const...

great, I am trying to make `comment-parser` a flexible low-level parser for tools like this. > One thing I would like to investigate is if the comment-parser tokenizer can be...

This is reasonable suggestion, I will try to make it configurable in upcoming 1.0

@bennypowers that is definitely a reasonable suggestion. There is an alternative, more flexible approach though. The `spacing` option was intentionally kept limited to avoid complexity. But all the variation one...