1 | /**
|
2 | * Doc Comment parsing
|
3 | *
|
4 | * I tried using TSDoc here.
|
5 | *
|
6 | * Pro:
|
7 | * - Future standard.
|
8 | * - Does validating parsing and complains on failure.
|
9 | * - Has a more flexible interpretation of the @example tag (starts in text mode).
|
10 | *
|
11 | * Con:
|
12 | * - Different tags from JSDoc (@defaultValue instead of @default, "@param name
|
13 | * description" instead "@param name description".
|
14 | * - @example tag has a different interpretation than VSCode and JSDoc
|
15 | * (VSCode/JSDoc starts in code mode), which is confusing for syntax
|
16 | * highlighting in the editor.
|
17 | * - Allows no unknown tags.
|
18 | * - Wants to be in charge of parsing TypeScript, integrating into other build is
|
19 | * possible but harder.
|
20 | * - Parse to a DOM with no easy way to roundtrip back to equivalent MarkDown.
|
21 | *
|
22 | * Especially the last point: while parsing to and storing the parsed docs DOM
|
23 | * in the jsii assembly is superior in the long term (for example for
|
24 | * converting to different output formats, JavaDoc, C# docs, refdocs which all
|
25 | * accept slightly different syntaxes), right now we can get 80% of the bang
|
26 | * for 10% of the buck by just reading, storing and reproducing MarkDown, which
|
27 | * is Readable Enough(tm).
|
28 | *
|
29 | * If we ever want to attempt TSDoc again, this would be a good place to look at:
|
30 | *
|
31 | * https://github.com/Microsoft/tsdoc/blob/master/api-demo/src/advancedDemo.ts
|
32 | */
|
33 | import * as spec from '@jsii/spec';
|
34 | import * as ts from 'typescript';
|
35 | /**
|
36 | * Parse all doc comments that apply to a symbol into JSIIDocs format
|
37 | */
|
38 | export declare function parseSymbolDocumentation(sym: ts.Symbol, typeChecker: ts.TypeChecker): DocsParsingResult;
|
39 | /**
|
40 | * Return the list of parameter names that are referenced in the docstring for this symbol
|
41 | */
|
42 | export declare function getReferencedDocParams(sym: ts.Symbol): string[];
|
43 | export interface DocsParsingResult {
|
44 | docs: spec.Docs;
|
45 | hints: TypeSystemHints;
|
46 | diagnostics?: string[];
|
47 | }
|
48 | export interface TypeSystemHints {
|
49 | /**
|
50 | * Only present on interfaces. This indicates that interface must be handled as a struct/data type
|
51 | * even through it's name starts with a capital letter `I`.
|
52 | */
|
53 | struct?: boolean;
|
54 | }
|
55 | /**
|
56 | * Split the doc comment into summary and remarks
|
57 | *
|
58 | * Normally, we'd expect people to split into a summary line and detail lines using paragraph
|
59 | * markers. However, a LOT of people do not do this, and just paste a giant comment block into
|
60 | * the docstring. If we detect that situation, we will try and extract the first sentence (using
|
61 | * a period) as the summary.
|
62 | */
|
63 | export declare function splitSummary(docBlock: string | undefined): [string | undefined, string | undefined];
|
64 | //# sourceMappingURL=docs.d.ts.map |
\ | No newline at end of file |