tools: update marked to 0.4.0 #21081

Trott · 2018-06-01T11:29:00Z

Update marked to 0.4.0 for use with the tools/doc/*.js tools.

Ref: https://nodesecurity.io/advisories/531

(Yes, that is extraordinarily unlikely to impact us in this context.)

@styfle @vsemozhetbyt

Checklist

make -j4 test (UNIX), or vcbuild test (Windows) passes
commit message follows commit guidelines

richardlau · 2018-06-01T11:32:43Z

tools/doc/node_modules/marked/LICENSE

@@ -1,19 +0,0 @@
-Copyright (c) 2011-2014, Christopher Jeffrey (https://github.com/chjj/)


We'll have to fix the license-builder script:

node/tools/license-builder.sh

Lines 74 to 75 in 7dca329

addlicense "marked" "tools/doc/node_modules/marked" \

"$(cat ${rootdir}/tools/doc/node_modules/marked/LICENSE)"

Updated license-builder.sh. Thanks.

styfle · 2018-06-01T13:46:04Z

@Trott Why is the node_modules folder checked in?
I wasn't expecting to see the source code of marked here 😆

Trott · 2018-06-01T14:19:32Z

@Trott Why is the node_modules folder checked in?

I'm not 100% sure, but I imagine the problem it is supposed to solve is probably solved by package-lock.json.

vsemozhetbyt · 2018-06-01T14:27:08Z

@Trott I shall try to check if there are any breaking changes in our HTML/JSON docs with this update. Last time I've checked, there were some.

styfle · 2018-06-01T14:41:13Z

Is there a build step to generate all the HTML files?
I want to try this on my local machine but all I see is a generate.js asking for a filename?

Trott · 2018-06-01T14:44:37Z

@styfle make doc (and make test-doc too)

vsemozhetbyt · 2018-06-01T14:49:32Z

To build just any doc:

node tools/doc/generate.js --format=json doc/api/all.md > all.json
node tools/doc/generate.js --format=html --node-version=11.0.0 --analytics= doc/api/all.md > all.html

styfle · 2018-06-01T14:54:59Z

tools/doc/node_modules/.bin/marked

@@ -0,0 +1 @@
+../marked/bin/marked


Can you do this to remove node modules?

cd tools/doc && echo 'node_modules' > .gitignore && rm -rf node_modules && git add -A

We have other tools directory node_modules subdirectories listed as ignored in the top-level .gitignore so putting it there is probably the way to go.

Also, we'd need to add an npm install step for that directory in Makefile and vcbuild.bat similar to lint-md-build.

Is it going to cause a problem to run npm install each time in the Makefile?
I'm still new to the build tools 😅

@nodejs/build ^^^^^

@styfle @Trott Probably not a big issue, but would obviously be better to avoid doing so (would cause longer build times)

Probably not a big issue, but would obviously be better to avoid doing so (would cause longer build times)

I guess that might explain checking in the node_modules directory. :-D

vsemozhetbyt · 2018-06-02T10:03:16Z

I've started to check the diff in HTML and JSON output before and after this upgrade. There are many insignificant changes: white spaces (+/- line breaks), code blocks class names (class="lang- -> class="language-), list metadata, HTML entities vs. verbatim symbols etc.

But here is the first detected really breaking change:

Before:

After:

Cause: markdown links are not rendered as links inside HTML markup.

Small test to check:

'use strict';

const marked = require('marked');

const md = `
<div>A [link][].</div>

[link]: #hash
`;

const tokens = marked.lexer(md);
console.log(tokens);

const html = marked.parser(tokens);
console.log(`\n${html}`);

With the current version:

[ { type: 'html', pre: false, text: '<div>A [link][].</div>\n\n' },
  links: { link: { href: '#hash', title: undefined } } ]

<div>A <a href="#hash">link</a>.</div>

With the new version:

[ { type: 'html', pre: false, text: '<div>A [link][].</div>\n\n' },
  links: { link: { href: '#hash', title: undefined } } ]

<div>A [link][].</div>

vsemozhetbyt · 2018-06-02T10:22:02Z

This issue concerns not links only, but all Markdown markup inside HTML markup (code fragments in backticks are not rendered as code too, for example).

vsemozhetbyt · 2018-06-02T15:40:36Z

Issue 2, more complicated.

Before (5 links with right texts and URLs):

After (3 links with wrong text and URLs + 2 code spans instead of links):

Cause: some combination of links with backticks (some of them are in full form like [text][ref], some of them are contracted like [text-as-ref]) baffles parser and produces very tangled output.

Reduced test case with the same pattern as in the source above:

'use strict';

const marked = require('marked');

const md = `
Links: [\`link1\`] and [\`link2\`] and [\`link3\`] and
[\`link 4\`][\`link4\`] and [\`link 4\`][\`link4\`], end.

[\`link1\`]: #hash1
[\`link2\`]: #hash2
[\`link3\`]: #hash3
[\`link4\`]: #hash4
`;

const tokens = marked.lexer(md);
console.log(tokens);

const html = marked.parser(tokens);
console.log(`\n${html}`);

With the current version:

[ { type: 'paragraph',
    text:
     'Links: [`link1`] and [`link2`] and [`link3`] and\n[`link 4`][`link4`] and [`link 4`][`link4`], end.' },
  links: { '`link1`': { href: '#hash1', title: undefined },
    '`link2`': { href: '#hash2', title: undefined },
    '`link3`': { href: '#hash3', title: undefined },
    '`link4`': { href: '#hash4', title: undefined } } ]

<p>Links: <a href="#hash1"><code>link1</code></a> and <a href="#hash2"><code>link2</code></a> and <a href="#hash3"><code>link3</code></a> and
<a href="#hash4"><code>link 4</code></a> and <a href="#hash4"><code>link 4</code></a>, end.</p>

With the new version:

[ { type: 'paragraph',
    text:
     'Links: [`link1`] and [`link2`] and [`link3`] and\n[`link 4`][`link4`] and [`link 4`][`link4`], end.' },
  { type: 'space' },
  links: { '`link1`': { href: '#hash1', title: undefined },
    '`link2`': { href: '#hash2', title: undefined },
    '`link3`': { href: '#hash3', title: undefined },
    '`link4`': { href: '#hash4', title: undefined } } ]

<p>Links: <a href="#hash4"><code>link1</code>] and <a href="#hash4"><code>link2</code>] and <a href="#hash3"><code>link3</code></a> and
[<code>link 4</code></a> and [<code>link 4</code></a>, end.</p>

styfle · 2018-06-02T16:37:44Z

Possibly related: markedjs/marked#1263

vsemozhetbyt · 2018-06-02T17:54:31Z

Issue 1.2. Most likely related to the first issue: text links inside HTML markup are not auto-linkified.

Before:

After:

Small test:

'use strict';

const marked = require('marked');

const md = `
<table><tr><td>
See https://example.org for more info.
</td></tr></table>
`;

const tokens = marked.lexer(md);
console.log(tokens);

const html = marked.parser(tokens);
console.log(`\n${html}`);

With the current version:

[ { type: 'html',
    pre: false,
    text:
     '<table><tr><td>\nSee https://example.org for more info.\n</td></tr></table>\n' },
  links: {} ]

<table><tr><td>
See <a href="https://example.org">https://example.org</a> for more info.
</td></tr></table>

With the new version:

[ { type: 'html',
    pre: false,
    text:
     '<table><tr><td>\nSee https://example.org for more info.\n</td></tr></table>\n' },
  links: {} ]

<table><tr><td>
See https://example.org for more info.
</td></tr></table>

vsemozhetbyt · 2018-06-02T19:31:46Z

Issue 3. Period is wrongly included in URL of auto-linkified text link inside parentheses.

Before:

After:

Small test:

'use strict';

const marked = require('marked');

const md = `
(See https://github.com/nodejs/node/pull/12562.)
`;

const tokens = marked.lexer(md);
console.log(tokens);

const html = marked.parser(tokens);
console.log(`\n${html}`);

With the current version:

[ { type: 'paragraph',
    text: '(See https://github.com/nodejs/node/pull/12562.)' },
  links: {} ]

<p>(See <a href="https://github.com/nodejs/node/pull/12562">https://github.com/nodejs/node/pull/12562</a>.)</p>

With the new version:

[ { type: 'paragraph',
    text: '(See https://github.com/nodejs/node/pull/12562.)' },
  links: {} ]

<p>(See <a href="https://github.com/nodejs/node/pull/12562.">https://github.com/nodejs/node/pull/12562.</a>)</p>

vsemozhetbyt · 2018-06-02T20:27:59Z

Issue 4. Markdown tables are not rendered.

Before:

After:

Small test:

'use strict';

const marked = require('marked');

const md = `

| a | b |
|-------|
| c | d |

`;

const tokens = marked.lexer(md);
console.log(tokens);

const html = marked.parser(tokens);
console.log(`\n${html}`);

With the current version:

[ { type: 'space' },
  { type: 'table',
    header: [ 'a', 'b' ],
    align: [ null ],
    cells: [ [Array] ] },
  links: {} ]

<table>
<thead>
<tr>
<th>a</th>
<th>b</th>
</tr>
</thead>
<tbody>
<tr>
<td>c</td>
<td>d</td>
</tr>
</tbody>
</table>

With the new version:

[ { type: 'space' },
  { type: 'paragraph', text: '| a | b |\n|-------|\n| c | d |' },
  { type: 'space' },
  links: {} ]

<p>| a | b |
|-------|
| c | d |</p>

vsemozhetbyt · 2018-06-02T21:09:53Z

Issue 5. Tricky one.

Before:

After:

Cause: Links with bottom references that clash with Object.prototype properties are ignored by the lexer and are not rendered.

Small test:

'use strict';

const marked = require('marked');

const md = `

Link: [constructor][].

[constructor]: https://example.org/

`;

const tokens = marked.lexer(md);
console.log(tokens);

const html = marked.parser(tokens);
console.log(`\n${html}`);

With the current version:

[ { type: 'space' },
  { type: 'paragraph', text: 'Link: [constructor][].' },
  links: { constructor: { href: 'https://example.org/', title: undefined } } ]

<p>Link: <a href="https://example.org/">constructor</a>.</p>

With the new version:

[ { type: 'space' },
  { type: 'paragraph', text: 'Link: [constructor][].' },
  { type: 'space' },
  links: {} ]

<p>Link: [constructor][].</p>

vsemozhetbyt · 2018-06-02T21:29:51Z

It seems this is all I could find. The new version also resolves conflicting references (see #20100) in a different way, but this is our mess and we can ignore this for now.

However, we may need to wait for fixing above-enumerated issues before the upgrade.

Trott · 2018-06-03T12:42:57Z

Thanks for finding and clearly detailing all the issues that need to be addressed, @vsemozhetbyt! Labeling in progress for now.

Trott · 2018-06-19T21:53:22Z

markdown links are not rendered as links inside HTML markup.

@vsemozhetbyt That appears to be a bug in our markdown and not a bug in the marked library.

https://daringfireball.net/projects/markdown/syntax#html:

Note that Markdown formatting syntax is not processed within block-level HTML tags.

Trott · 2018-06-19T21:54:54Z

@vsemozhetbyt That appears to be a bug in our markdown and not a bug in the marked library.

Solution is probably to have html.js process the markdown before adding the div tag. I'll see about doing that as part of this PR.

Trott · 2018-06-20T04:05:43Z

Solution is probably to have html.js process the markdown before adding the div tag. I'll see about doing that as part of this PR.

Well, that was a bit long on the debugging front, but it turns out the solution was to remove a single unnecessary line from html.js. That resolved issue 1 identified by @vsemozhetbyt (with the amazingly helpful screenshots--thanks so much for all the work identifying the problems and providing excellent bug reports in the form of those comments with images!). Now to hope the other issues can be resolved more promptly...

vsemozhetbyt · 2018-06-30T08:11:10Z

We still have to do something with markdown inside HTML.

The source in crypto.md:

  <tr>
    <td><code>RSA_PSS_SALTLEN_DIGEST</code></td>
    <td>Sets the salt length for `RSA_PKCS1_PSS_PADDING` to the digest size
        when signing or verifying.</td>
  </tr>
  <tr>
    <td><code>RSA_PSS_SALTLEN_MAX_SIGN</code></td>
    <td>Sets the salt length for `RSA_PKCS1_PSS_PADDING` to the maximum
        permissible value when signing data.</td>
  </tr>
  <tr>
    <td><code>RSA_PSS_SALTLEN_AUTO</code></td>
    <td>Causes the salt length for `RSA_PKCS1_PSS_PADDING` to be determined
        automatically when verifying a signature.</td>
  </tr>

Before:

  <tr>
    <td><code>RSA_PSS_SALTLEN_DIGEST</code></td>
    <td>Sets the salt length for <code>RSA_PKCS1_PSS_PADDING</code> to the digest size
        when signing or verifying.</td>
  </tr>
  <tr>
    <td><code>RSA_PSS_SALTLEN_MAX_SIGN</code></td>
    <td>Sets the salt length for <code>RSA_PKCS1_PSS_PADDING</code> to the maximum
        permissible value when signing data.</td>
  </tr>
  <tr>
    <td><code>RSA_PSS_SALTLEN_AUTO</code></td>
    <td>Causes the salt length for <code>RSA_PKCS1_PSS_PADDING</code> to be determined
        automatically when verifying a signature.</td>
  </tr>

After (see preserved backticks instead of <code> elements):

  <tr>
    <td><code>RSA_PSS_SALTLEN_DIGEST</code></td>
    <td>Sets the salt length for `RSA_PKCS1_PSS_PADDING` to the digest size
        when signing or verifying.</td>
  </tr>
  <tr>
    <td><code>RSA_PSS_SALTLEN_MAX_SIGN</code></td>
    <td>Sets the salt length for `RSA_PKCS1_PSS_PADDING` to the maximum
        permissible value when signing data.</td>
  </tr>
  <tr>
    <td><code>RSA_PSS_SALTLEN_AUTO</code></td>
    <td>Causes the salt length for `RSA_PKCS1_PSS_PADDING` to be determined
        automatically when verifying a signature.</td>
  </tr>

Also in fs.md:

    <td>Flag indicating reading accesses to the file system will no longer
    result in an update to the `atime` information associated with the file.
    This flag is available on Linux operating systems only.</td>

Also several fragments in os.md tables.

Also stream.md produces unrendered links in tables for the same reason.

vsemozhetbyt · 2018-06-30T08:17:43Z

Another example of issue 1:
errors.md:

For *all* [`EventEmitter`][] objects, if an `'error'` event handler is not
provided, the error will be thrown, causing the Node.js process to report an
uncaught exception and crash unless either: The [`domain`][domains] module is
used appropriately or a handler has been registered for the
[`'uncaughtException'`][] event.

Before:

<p>For <em>all</em> <a href="events.html#events_class_eventemitter"><code>EventEmitter</code></a> objects, if an <code>&#39;error&#39;</code> event handler is not
provided, the error will be thrown, causing the Node.js process to report an
uncaught exception and crash unless either: The <a href="domain.html"><code>domain</code></a> module is
used appropriately or a handler has been registered for the
<a href="process.html#process_event_uncaughtexception"><code>&#39;uncaughtException&#39;</code></a> event.</p>

After:

<p>For <em>all</em> <a href="domain.html"><code>EventEmitter</code>][] objects, if an <code>&#39;error&#39;</code> event handler is not
provided, the error will be thrown, causing the Node.js process to report an
uncaught exception and crash unless either: The [<code>domain</code></a> module is
used appropriately or a handler has been registered for the
<a href="process.html#process_event_uncaughtexception"><code>&#39;uncaughtException&#39;</code></a> event.</p>

Also in net.md, these fragments produce similar mess:

Source:

### net.createConnection(path[, connectListener])
<!-- YAML
added: v0.1.90
-->

* `path` {string} Path the socket should connect to. Will be passed to
  [`socket.connect(path[, connectListener])`][`socket.connect(path)`].
  See [Identifying paths for IPC connections][].
* `connectListener` {Function} Common parameter of the
  [`net.createConnection()`][] functions, an "once" listener for the
  `'connect'` event on the initiating socket. Will be passed to
  [`socket.connect(path[, connectListener])`][`socket.connect(path)`].
* Returns: {net.Socket} The newly created socket used to start the connection.

Initiates an [IPC][] connection.

This function creates a new [`net.Socket`][] with all options set to default,
immediately initiates connection with
[`socket.connect(path[, connectListener])`][`socket.connect(path)`],
then returns the `net.Socket` that starts the connection.

### net.createConnection(port[, host][, connectListener])
<!-- YAML
added: v0.1.90
-->

* `port` {number} Port the socket should connect to. Will be passed to
  [`socket.connect(port[, host][, connectListener])`][`socket.connect(port, host)`].
* `host` {string} Host the socket should connect to. Will be passed to
  [`socket.connect(port[, host][, connectListener])`][`socket.connect(port, host)`].
   **Default:** `'localhost'`.
* `connectListener` {Function} Common parameter of the
  [`net.createConnection()`][] functions, an "once" listener for the
  `'connect'` event on the initiating socket. Will be passed to
  [`socket.connect(path[, connectListener])`][`socket.connect(port, host)`].
* Returns: {net.Socket} The newly created socket used to start the connection.

Initiates a TCP connection.

This function creates a new [`net.Socket`][] with all options set to default,
immediately initiates connection with
[`socket.connect(port[, host][, connectListener])`][`socket.connect(port, host)`],
then returns the `net.Socket` that starts the connection.

Also many problem fragments in stream.md like these:

The `writable.cork()` method forces all written data to be buffered in memory.
The buffered data will be flushed when either the [`stream.uncork()`][] or
[`stream.end()`][stream-end] methods are called.

For backwards compatibility reasons, removing [`'data'`][] event handlers will
**not** automatically pause the stream. Also, if there are piped destinations,
then calling [`stream.pause()`][stream-pause] will not guarantee that the
stream will *remain* paused once those destinations drain and ask for more data.

vsemozhetbyt · 2018-06-30T08:50:30Z

I've updated the last comments with more examples.

Sum up: on this stage, we still have 2 issues with the new marked version: 1) some pattern with several consecutive markdown links produses a mess and 2) markdown code and link fragments are not processed inside HTML tables.

Remove unneeded line that will cause links to break when we update to marked 0.4.0.

Simplify the inline markdown in buffer.md. Admission: This is to work around an issue that arises when this markdown is processed by `marked` v0.4.0.

Links in crypto.md table had previously been autolinking, but correct Mardkwon processing will not autolink in block elements like tables. Upcoming marked 0.4.0 will not autolink in this instance, so add the links as anchor elements.

Update marked to 0.4.0 for use with the tools/doc/*.js tools.

Float a patch to deal with punctuation at the end of URLs in a more robust fashion. Refs: markedjs/marked#1293

Float a patch to deal with empty table cells. Refs: markedjs/marked#1262

Float a patch on marked-0.4.0 that fixes a bug that breaks links that are named the same as properties on the Object prototype. Refs: markedjs/marked#1299

Trott · 2018-07-02T17:54:13Z

Issue 1 is a bug in marked that is non-trivial to fix without breaking other things, but I'll try.

Issue 2 is a bug in our markdown and I wouldn't be surprised if other markdown processors also had the same issue. For those, I'll try to fix our markdown.

AyushG3112 · 2018-07-02T18:09:45Z

In case we float any patches, would it be viable to note them as things to take care of when the nodejs website is redesigned, which is being thought about, according to this issue: nodejs/nodejs.org#1534 ?

rubys · 2018-07-02T18:18:06Z

@Trott I'm curious as to the bug in our markdown? The following works with both marked and remark:

'use strict';

const marked = require('marked');

const unified = require('unified');
const markdown = require('remark-parse');
const remark2rehype = require('remark-rehype');
const html = require('rehype-stringify');
const raw = require('rehype-raw');

const testData = `
|   h   |  h  |     h     |
|-------|-----|-----------|
|<b>x<b>|**x**|[x](a.html)|
`

console.log('marked:');
console.log(marked(testData));

console.log('');

console.log('unified/remark/rehype:');
console.log(unified()
  .use(markdown)
  .use(remark2rehype, {allowDangerousHTML: true})
  .use(raw)
  .use(html)
  .processSync(testData).toString().trim());

Trott · 2018-07-02T18:25:27Z

@rubys Yes, that example seems to work correctly in both. Markdown inside a markdown table is 👍.

This code should show the issue. Markdown inside HTML block elements should not be expanded:

<table>
<tr>
<td>**should not be bold**</td>
</tr>
</table>

Some of our docs have markdown inside HTML table elements. According to markdown specs as I understand them, that markdown should not be expanded. It was expanded in marked 0.3.5 and that's a bug that's fixed in marked 0.4.0. Unfortunately, we're relying on that bug.

rubys · 2018-07-02T19:12:59Z

@Trott gotcha. I verified that that marked 0.4 and remark produce the same output for that input. Note: given how unified pipelining works, it would not be difficult to write a processor that looks for text nodes within a table and expand them. It could even look for tables with a given data-somethingorother attribute defined, and only process those tables. This could also be done with marked by looking at the lexed tokens.

rubys · 2018-07-09T23:33:57Z

Question: what is the status of this effort, and on evaluating the possible conversion to remark? I ask because it may impact other work.

At the moment, it seems clear that remark is easier to extend cleanly, but runs slower. Moving the generation of all.html and all.json away from reprocessing the input (done) and generating both the html and json in one pass (planned) will mitigate the performance difference. The generation of JSON isn't complete, but a proof of concept has been posted.

marked also seems less "spec compliant" and more prone to change from release to release, but that might be because we don't have enough experience with remark.

Additionally, the build process for node already is using remark... it would be ideal to consolidate to one markdown engine.

Am I missing anything? (And, yes, at this point I may be biased :-) )

vsemozhetbyt · 2018-07-10T01:53:48Z

As for the new toolchain with remark, one of the possible concerns to be considered is the learning curve. We have a very small collaborators group that is aware of doc tools infrastructure. The current tooling was rather old and tangled and there still was not so big interest in changing it. I am just afraid if we will have enough collaborators to maintain the new tooling in an effective, responsive and updatable state. It may be not good to have a too small doc tool collaborators team more like a closed esoteric sect.

Trott · 2018-07-10T02:03:00Z

I think the effort of @rubys to get remark in place is exceedingly likely to be completed before this is. And I think if that happens, we'll at least have @rubys as someone who understands the tooling. :-D

I'm leaving this open because I will indeed push it forward if something happens to the remark effort that stalls it. But I don't foresee that.

I'm also leaving it open as a to-do list of fixing the table markup in places where it is not compliant.

I would encourage moving ahead with remark. But @vsemozhetbyt (and possibly others) may have legitimate reservations that need to be considered.

rubys · 2018-07-12T17:20:50Z

I was originally going to say something rather meek like "as someone new to both marked and remark, I find remark more approachable", but having just completed my first pass at updating the conversion to JSON, it is clear that current marked based code to produce JSON is essentially unmaintainable. I've surfaced a number of issues in #21697, but the full set of differences can be found by looking for continue and return statements in jsondiff. While it is possible that a few of these are misunderstandings on my part, the bulk are clearly wrong.

As a byproduct of this effort, I compared the output of the conversions for every description, and will submit a separate pull request with changes to the markdown to make it work with both sets of toolchains.

Trott · 2018-07-12T17:42:49Z

I'm feeling good about the progress @rubys has been making moving to remark and #21780 deals with all the quirks that I was going to get around to sooner or later, so I'm inclined to close this at this point. We can always re-open it if the move to remark stalls or hits an unforeseen insurmountable problem.

vsemozhetbyt · 2018-07-12T18:03:42Z

The problem with doctools is that they are rather old and it seems we may have no active collaborators that created them. I've done some cleanup in doctools this spring and json.js was the most complicated one, sometimes I felt that I went in darkness or minefield) Moreover, I had no context about the use cases for JSON results or any criteria for required completeness and validness of the results. So if anybody wants to even completely recreate the json tools contacting with JSON users, this may be the best, if they can maintain the new scripts to some extent.

rubys · 2018-07-12T18:49:45Z

If we can make progress landing the changes I've made to convert from marked to remark, I'll certainly support the code. If you are looking for somebody to own the current marked based implementation of JSON generation... sorry, but I would need to throw a ENOTME Error on that. :-)

vsemozhetbyt · 2018-07-12T19:01:53Z

Any tool will do with a human being helping, I think)

tolmasky · 2018-07-12T19:03:59Z

The RunKit team certainly has a vested interest in both the JSON generation (which I guess we might be the sole known consumers of?) as well as the documentation. We'd certainly be willing to help or take ownership or provide assistance in whatever way would be most helpful.

…

On Thu, Jul 12, 2018 at 11:50 AM Sam Ruby ***@***.***> wrote: If we can make progress landing the changes I've made to convert from marked to remark, I'll certainly support the code. If you are looking for somebody to own the current marked based implementation of JSON generation... sorry, but I would need to throw a ENOTME Error on that. :-) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#21081 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABcyZKj4SVPPMhpgPYmbE49RF8c-mtTks5uF5qPgaJpZM4UWin-> .

-- Francisco Tolmasky www.tolmasky.com tolmasky@gmail.com

vsemozhetbyt · 2018-07-12T19:06:35Z

We state JSON output as experimental now, so it seems we have any wiggle room we want.

Trott requested a review from a team as a code owner June 1, 2018 11:29

nodejs-github-bot added doc Issues and PRs related to the documentations. tools Issues and PRs related to the tools directory. labels Jun 1, 2018

Trott removed the request for review from a team June 1, 2018 11:29

richardlau previously requested changes Jun 1, 2018

View reviewed changes

styfle reviewed Jun 1, 2018

View reviewed changes

nodejs deleted a comment from refack Jun 1, 2018

Trott added the wip Issues and PRs that are still a work in progress. label Jun 3, 2018

Trott force-pushed the marked-0.4.0 branch 2 times, most recently from 514bea0 to 09cdca8 Compare June 19, 2018 20:10

Trott force-pushed the marked-0.4.0 branch from 09cdca8 to f6dabe0 Compare June 20, 2018 04:06

vsemozhetbyt mentioned this pull request Jun 30, 2018

Produce HTML documentation using unified/remark/rehype #21490

Closed

3 tasks

Trott added 7 commits July 1, 2018 19:40

tools: remove unnecessary line in html.js

18ba154

Remove unneeded line that will cause links to break when we update to marked 0.4.0.

doc: simplify buffer.md markdown

e041220

Simplify the inline markdown in buffer.md. Admission: This is to work around an issue that arises when this markdown is processed by `marked` v0.4.0.

doc: add links to inline HTML table

25741dc

Links in crypto.md table had previously been autolinking, but correct Mardkwon processing will not autolink in block elements like tables. Upcoming marked 0.4.0 will not autolink in this instance, so add the links as anchor elements.

tools: update marked to 0.4.0

676c1bb

Update marked to 0.4.0 for use with the tools/doc/*.js tools.

tools: float punctuation patch on marked-0.4.0

52ac8c9

Float a patch to deal with punctuation at the end of URLs in a more robust fashion. Refs: markedjs/marked#1293

tools: float empty cell patch on marked-0.4.0

ece7854

Float a patch to deal with empty table cells. Refs: markedjs/marked#1262

tools: float prototype patch on marked-0.4.0

10be56c

Float a patch on marked-0.4.0 that fixes a bug that breaks links that are named the same as properties on the Object prototype. Refs: markedjs/marked#1299

Trott force-pushed the marked-0.4.0 branch from 6b5f4b1 to 10be56c Compare July 2, 2018 02:43

Trott closed this Jul 12, 2018

Trott mentioned this pull request Aug 8, 2018

Update dependencies nodejs/nodejs.org#1764

Merged

Trott deleted the marked-0.4.0 branch January 13, 2022 22:49

		@@ -1,19 +0,0 @@
		Copyright (c) 2011-2014, Christopher Jeffrey (https://github.com/chjj/)

	addlicense "marked" "tools/doc/node_modules/marked" \
	"$(cat ${rootdir}/tools/doc/node_modules/marked/LICENSE)"

		@@ -0,0 +1 @@
		../marked/bin/marked

tools: update marked to 0.4.0 #21081

tools: update marked to 0.4.0 #21081

Conversation

Trott commented Jun 1, 2018

Checklist

richardlau Jun 1, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

styfle commented Jun 1, 2018

Trott commented Jun 1, 2018

vsemozhetbyt commented Jun 1, 2018

styfle commented Jun 1, 2018

Trott commented Jun 1, 2018

vsemozhetbyt commented Jun 1, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vsemozhetbyt commented Jun 2, 2018 • edited

vsemozhetbyt commented Jun 2, 2018 • edited

vsemozhetbyt commented Jun 2, 2018

Issue 2, more complicated.

styfle commented Jun 2, 2018

vsemozhetbyt commented Jun 2, 2018 • edited

vsemozhetbyt commented Jun 2, 2018

vsemozhetbyt commented Jun 2, 2018 • edited

vsemozhetbyt commented Jun 2, 2018

vsemozhetbyt commented Jun 2, 2018

Trott commented Jun 3, 2018

Trott commented Jun 19, 2018

Trott commented Jun 19, 2018

Trott commented Jun 20, 2018

vsemozhetbyt commented Jun 30, 2018 • edited

vsemozhetbyt commented Jun 30, 2018 • edited

vsemozhetbyt commented Jun 30, 2018

Trott commented Jul 2, 2018

AyushG3112 commented Jul 2, 2018 • edited

rubys commented Jul 2, 2018

Trott commented Jul 2, 2018 • edited

rubys commented Jul 2, 2018

rubys commented Jul 9, 2018

vsemozhetbyt commented Jul 10, 2018 • edited

Trott commented Jul 10, 2018

rubys commented Jul 12, 2018

Trott commented Jul 12, 2018

vsemozhetbyt commented Jul 12, 2018 • edited

rubys commented Jul 12, 2018

vsemozhetbyt commented Jul 12, 2018

tolmasky commented Jul 12, 2018 via email

vsemozhetbyt commented Jul 12, 2018

richardlau Jun 1, 2018 •

edited

vsemozhetbyt commented Jun 1, 2018 •

edited

vsemozhetbyt commented Jun 2, 2018 •

edited

vsemozhetbyt commented Jun 2, 2018 •

edited

vsemozhetbyt commented Jun 2, 2018 •

edited

vsemozhetbyt commented Jun 2, 2018 •

edited

vsemozhetbyt commented Jun 30, 2018 •

edited

vsemozhetbyt commented Jun 30, 2018 •

edited

AyushG3112 commented Jul 2, 2018 •

edited

Trott commented Jul 2, 2018 •

edited

vsemozhetbyt commented Jul 10, 2018 •

edited

vsemozhetbyt commented Jul 12, 2018 •

edited