Looks like it only reads /** … */ comments

[tomek-he-him]

How about mentioning that in the readme? I’m developing a cli for your library at https://github.com/studio-b12/get-comments-cli. It cost me some debugging :)

[tunnckoCore]

It is mentioned:

It extracts only first level block comments

and thanks for

I’m developing a cli for your library at

[tomek-he-him]

TBH I’ve no idea what “first level” means.

BTW /* … */ is also a block comment.

getComments('code\n/** comment */\ncode', true)
//» [ { start: 5,
//      end: 19,
//      type: 'Block',
//      loc: { start: [Object], end: [Object] },
//      api: false,
//      value: '* comment ',
//      after: 'code' } ]

getComments('code\n/* comment */\ncode', true)
//» []

[tunnckoCore]

TBH I’ve no idea what “first level” means.

Not nested. e.g.

/**
 * docs1
 */

module.exports = function () {
    /**
     * without that
     * @type {Object}
     */
    var identifier = ipFilter(id, options.filter, !strict)
}

/**
 * docs2
 */

module.exports.data = function () {
    /* nope yeah */
    return 'foobar' /* nope */
}

here, you will got only docs1 and docs2 comments

BTW /* … */ is also a block comment.

Know. Just these libs around are POCs (and fun and perf testing) for documentation generator from jsdocs comments. Because of that all other type of comments are ignored by default. It's intentional.

[tomek-he-him]

Well, I guess a good library should be a balance between focused and generic. When it’s too focused, it may be super useful to you but not to anyone else.

That’s why I didn’t like https://github.com/jonschlinkert/extract-comments – it just does too much, and isn’t generic at all.

But TBH I’m not looking for a proof-of-concept library but for a well-tested solid base. I originally liked the simplicity of your lib except for the non-generic parts like https://github.com/tunnckoCore/get-comments/blob/b6a0351/index.js#L41 and https://github.com/tunnckoCore/get-comments/blob/b6a0351/index.js#L53.

Please let me know when your lib is stable.

[tomek-he-him]

By the way I also use this for generating docs – but

• not necessarily using jsDoc (there are alternatives) – and
• not necessarily within level-zero indentation (e.g. sometimes the API is created within a closure)

Will your library support these use cases?

[tunnckoCore]

e.g. sometimes the API is created within a closure

i realize that and that's why i notify users at the readme. it just implement bare minimum and most used case - simple modules and classes - with assumption that comments are jsdoc, cuz they are used the most.

about the #L41.. why some would use just /* */ comments to describe api i cant got it. and if someone use them like that he must stop. and if we allow them it would 10x slower and harder to determine which comment is for what. it will produce more problems and tricks than it solves.

and no, maybe won't implement more than that here. firstly it would be slow, it have a huge amount of use cases and edge cases and that per character approach if it's not slow, it would be too tricky and hacky to cover them.

there's a tons of ways to do that shit, really - this is one of them, haha.

[tunnckoCore]

Please let me know when your lib is stable.

it is stable and pretty enough to handle 90% of the docs. i'll just try to fix the bugs when i have more time.

hm.. have an idea. i can expose option to pass each character to some fn and this will allow building things on top of it.

thanks again.

[tunnckoCore]

Are you tried https://github.com/tunnckoCore/acorn-extract-comments and fits your needs? Looks better and more logical to relay on.

I suppose that this would stay experimental, it's in his nature, my 2 cents.

[tomek-he-him]

I don’t want to use acorn because it requires a particular version of ES. If I soon have a module written in ES 2016 and acorn is lagging behind, it breaks. Even if acorn adapted fast to syntax changed (which it doesn’t), I’d still need to rely on you to update your dependency.

[tunnckoCore]

I don’t want to use acorn because it requires a particular version of ES

acorn-extract-comments support passing options directly to acorn. and acorn currently support more than esprima and would support it is well maintained and with fast release cycle. it currently support latest es6 features

I’d still need to rely on you to update your dependency.

im here every day and trying to do most of i can about my libs.

[tunnckoCore]

I also will review https://www.npmjs.com/package/acorn-6to5 for es7

[tomek-he-him]

There are other reasons as well. You can use JS-style comments in CSS, for example.

[tunnckoCore]

you can still write jsdoc style /** .. */ comments

/**
 * docs
 */
.foo {
  width: 200px;
}

[tunnckoCore]

Just always try to do the things in most rational way. Dont make your world harder. I can use just babel to parse that things and will have support for all you can mind, but that dependency is too big for users that just want to get comments from normal js code (es5-6)

or just babel-extract-comments is another good idea.

[tomek-he-him]

you can still write jsdoc style /* .. / comments

That was an argument why I don’t want acorn.

Just always try to do the things in most rational way. Dont make your world harder.

Please don’t patronize me.

It looks like you didn’t get my point. I meant exactly the opposite of pulling in babel as a dependency. Why use acorn (and babel, for that matter) if you can accomplish the same in a simpler way – getting flexibility for free.

[tunnckoCore]

if you can accomplish the same in a simpler way – getting flexibility for free.

you cant. im welcome for PR, im curios to see it.

as i said we experimentized with lot of implementations and there always have so much use cases and edge cases that we cant cover. so some battle-tested parser is the best option.