-
Notifications
You must be signed in to change notification settings - Fork 134
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Markdown lists. #178
Comments
@csr632 It has a built-in JSDoc comment parser that puts the tag content through a markdown to HTML transformer. In fact, I'm pretty sure it has support for most markdown features. |
Right, Monaco's default styler implements a scanner that recognizes various constructs that are commonly found in JavaScript/TypeScript doc comments. Of course, other editors like WebStorm may parse these comments differently. Whereas TSDoc's goals include establishing a rigorous spec that would enable various tools to parse doc comments, and agree on the interpretation. (For example, is |
Definitely agree with this - a common use case for me is documenting string union types, like this one: /**
* Open a file.
* @param path - the path to the file.
* @param mode - the file-opening mode to use. Possible values include:
*
* - `"w"` - basic 'write' mode; allows editing.
* - `"w+"` - advanced 'write' mode; allows editing and creates the file if it
* doesn't exist.
* - `"r"` - basic 'read' mode; allows reading but not editing.
*/
function openFile(path: string, mode: "w" | "w+" | "r"): string {
//...
} Of course, in many instances it might be better to use an enum and document each member, but sometimes that's too complex for a simple union, or the union might be pulled from something else (ie by using |
The problem I see currently is that the TSDoc emitter doesn't emit /**
* Compares this value with another value:
*
* - A negative value indicates this value is lesser.
* - A positive value indicates this value is greater.
* - A zero value indicates this value is the same.
*
* @param other The other value to compare against.
* @returns A number indicating the relational comparison result.
*/ However the "docComment": "/**\n * Compares this value with another value:\n *\n * - A negative value indicates this value is lesser. - A positive value indicates this value is greater. - A zero value indicates this value is the same.\n *\n * @param other - The other value to compare against.\n *\n * @returns A number indicating the relational comparison result.\n */\n", which looks like the following after a round-trip through the TSDoc parser and emitter: /**
* Compares this value with another value:
*
* - A negative value indicates this value is lesser. - A positive value indicates this value is greater. - A zero value indicates this value is the same.
*
* @param other - The other value to compare against.
*
* @returns A number indicating the relational comparison result.
*/ |
@rbuckton The word-wrapping is tracked by issue #200. |
From the linked issue, it seems the current behavior to trim insignificant whitespace is the culprit. The problem, as I see it, is that TSDoc's parser is making assumptions about what kind of whitespace is significant that is inconsistent with what Markdown considers to be insignificant whitespace. |
For https://tldraw.dev, we solved this by patching Patch here in case it's of use to anyone!
diff --git a/lib-commonjs/emitters/TSDocEmitter.js b/lib-commonjs/emitters/TSDocEmitter.js
index 36c607ac192810524ae28ce818d64652efedca98..41650ab83b6825d33b75fb86ec9b8eb0f0b5dfc7 100644
--- a/lib-commonjs/emitters/TSDocEmitter.js
+++ b/lib-commonjs/emitters/TSDocEmitter.js
@@ -278,6 +278,9 @@ var TSDocEmitter = /** @class */ (function () {
var docPlainText = docNode;
this._writeContent(docPlainText.text);
break;
+ case DocNode_1.DocNodeKind.SoftBreak:
+ this._ensureAtStartOfLine();
+ break;
}
};
TSDocEmitter.prototype._renderInlineTag = function (docInlineTagBase, writeInlineTagContent) {
diff --git a/lib-commonjs/transforms/TrimSpacesTransform.js b/lib-commonjs/transforms/TrimSpacesTransform.js
index 8d8a92b9a2c97347c29094df7d0e2b23cdcdffaf..6c5946e3f9adb61e46ce1d7d39ab07ee81db923e 100644
--- a/lib-commonjs/transforms/TrimSpacesTransform.js
+++ b/lib-commonjs/transforms/TrimSpacesTransform.js
@@ -18,6 +18,25 @@ var TrimSpacesTransform = /** @class */ (function () {
// We always trim leading whitespace for a paragraph. This flag gets set to true
// as soon as nonempty content is encountered.
var finishedSkippingLeadingSpaces = false;
+
+ function pushAccumulatedText() {
+ const lines = accumulatedTextChunks.join('').split('\n')
+ for (let i = 0; i < lines.length; i++) {
+ const line = lines[i]
+ transformedNodes.push(new nodes_1.DocPlainText({
+ configuration: docParagraph.configuration,
+ text: line
+ }));
+ if (i < lines.length - 1) {
+ transformedNodes.push(new nodes_1.DocSoftBreak({
+ configuration: docParagraph.configuration
+ }));
+ }
+ }
+ accumulatedTextChunks.length = 0;
+ accumulatedNodes.length = 0;
+ }
+
for (var _i = 0, _a = docParagraph.nodes; _i < _a.length; _i++) {
var node = _a[_i];
switch (node.kind) {
@@ -44,9 +63,15 @@ var TrimSpacesTransform = /** @class */ (function () {
}
break;
case nodes_1.DocNodeKind.SoftBreak:
- if (finishedSkippingLeadingSpaces) {
- pendingSpace = true;
- }
+ // by default, this transform strips out all soft-breaks and replaces them with
+ // spaces where needed. because we're rendering to markdown and markdown is
+ // whitespace-sensitive, we don't want to do this. instead, we accumulate the
+ // soft-breaks and emit them as normal.
+
+ // if (finishedSkippingLeadingSpaces) {
+ // pendingSpace = true;
+ // }
+ accumulatedTextChunks.push('\n');
accumulatedNodes.push(node);
break;
default:
@@ -58,12 +83,7 @@ var TrimSpacesTransform = /** @class */ (function () {
if (accumulatedTextChunks.length > 0) {
// TODO: We should probably track the accumulatedNodes somehow, e.g. so we can map them back to the
// original excerpts. But we need a developer scenario before we can design this API.
- transformedNodes.push(new nodes_1.DocPlainText({
- configuration: docParagraph.configuration,
- text: accumulatedTextChunks.join('')
- }));
- accumulatedTextChunks.length = 0;
- accumulatedNodes.length = 0;
+ pushAccumulatedText()
}
transformedNodes.push(node);
finishedSkippingLeadingSpaces = true;
@@ -71,12 +91,7 @@ var TrimSpacesTransform = /** @class */ (function () {
}
// Push the accumulated text
if (accumulatedTextChunks.length > 0) {
- transformedNodes.push(new nodes_1.DocPlainText({
- configuration: docParagraph.configuration,
- text: accumulatedTextChunks.join('')
- }));
- accumulatedTextChunks.length = 0;
- accumulatedNodes.length = 0;
+ pushAccumulatedText()
}
var transformedParagraph = new nodes_1.DocParagraph({
configuration: docParagraph.configuration |
We write our API docs in markdown embedded in tsdocs comments. vscode's hover preview of these docs renders them as expected, but api-extract treats whitespace as insignificant and strips out most newlines, which breaks markdown lists. See microsoft/tsdoc#178 for details. This PR patches tsdoc's emitter so that it preserves newlines. That way, we can write markdown lists and have them picked up as expected by the docs site markdown parser. I don't expect this to introduce other issues with previously ignored line breaks and markdown is only sensitive to linebreaks in certain scenarios (like lists) anyway. (Extracted from bindings docs - #3812) Before: <img width="740" alt="Screenshot 2024-05-22 at 15 00 43" src="https://github.com/tldraw/tldraw/assets/1489520/846f88b1-9480-48a6-9795-6a9f27ca242a"> After: <img width="708" alt="Screenshot 2024-05-22 at 14 51 28" src="https://github.com/tldraw/tldraw/assets/1489520/80c54b8e-4f74-45e7-9cba-0287175e9f97"> ### Change Type - [x] `docs` — Changes to the documentation, examples, or templates. - [x] `bugfix` — Bug fix
It would be useful to be able to include lists in doc comments:
The text was updated successfully, but these errors were encountered: