Martynas Žilinskas

@aciccarello the only usage of a single comment between symbol and JSDoc is tslint disable next line `// tslint:disable-next-line`.

I think there are two possible solutions. 1. Strict. JSDoc comment block must be in immediate previous line. ```ts class Foo { /** * Some documentation for `bar`. */ public...

I used @template in previous codebases. I think the word came from c++. @typeParam make more sense in TypeScript context.

@octogonz About the extend feature, it would be nice to have a support for packages. Similarly like how eslint works now, so you can publish as a separate package `@org/tsdoc-config`...

```ts // index.ts file in `example-package` // example-package/index:Foo#class class Foo { // example-package/index:Foo#class.a#property public a: string; } // example-package/index:Foo#namespace namespace Foo { // example-package/index:Foo#class.a#variable const a: number; } ``` We...

I upgraded `ts-extractor` to use this format of ids for ast items. {package-name}/{path-to-file}:{selector}#{kind}&{itemCounter} _Code sample:_ ```ts export function pickCard(x: { suit: string; card: number }[]): number; export function pickCard(x: number):...

@yume-chan The concern is not with performance, but how verbose can it become, like @pgonzal pointed out. The order of overload signatures matters, so numbering them makes sense. Consider this...

We discussed with @DovydasNavickas offline about handling `static` members. `#{kind/label}` format is no longer sufficient to specify only TypeScript syntax kinds and JSDoc `@label` tags. We think of allowing multiple...

In the newest prototype of `ts-extractor`, I encountered a few problems while generating AstItem's ids. I got more mature ideas about id format to be used. The format that will...

I agree with using `[ ]` brackets.