Missing space between Const and it's name

[KillyMXI]

I have a code that looks similar to this:

export type Bar<T, R> = (foos: Foo<T>[]) => R; // defined elsewhere

export const baz: Bar<string, string> = (foos) => '...';

Produced documentation looks like this:

## Functions

### baz

▸ `Const`**baz**(`foos`: [*Foo*](types.md#foo)<string\>[]): *string*

The last line renders like this:

▸ Constbaz(foos: Foo<string>[]): string

Note the absence of whitespace between Const and baz. (It might not be obvious depending on the styles but it copies as a single word.)

I did a quick look through the tests and it seems that the space is expected between Const and a variable name. Perhaps something wrong in this particular situation.

(Not sure what to think about the type Bar being expanded in the docs, but at least it's not wrong technically.)

[tgreyuk]

Thanks again.. fix in [email protected] ..

[KillyMXI]

Thank you!

[tgreyuk]

hi @KillyMXI

(Not sure what to think about the type Bar being expanded in the docs, but at least it's not wrong technically.)

I have actually been looking to reduce clutter with this kind of thing with the output below. Few more details here #230 .

Bar before

Bar after

baz before

baz after

[KillyMXI]

Hmm.
What I was referring to is the fact that type alias Bar is not present in the baz documentation, it is replaced by underlying type instead. But I guess it can't be helped.

Speaking of the proposed changes, they seem nice in general. Less duplication.
My initial reaction was that it might be harder to understand for type aliases specifically.
But I can feel like I'm gradually warming to the idea as I'm internalizing it.
Still, it is a bit marred by the fact there might be no way to describe parameters and return value for type aliases (@param and @returns don't work there as expected, iirc). One-liner type declaration might be a meaningful option to have.

Btw, here there are type aliases and corresponding markdown docs from the project that motivated this issue.

[tgreyuk]

Yes maybe it would be better to keep the one-liner type declarations for your use cases. I think will go for more subtle changes at this stage. Thanks again - very useful to have some feedback.