-
Notifications
You must be signed in to change notification settings - Fork 30k
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
Produce HTML documentation using unified/remark/rehype #21490
Conversation
Replacing the remainder of calls to
The coding parts I'm comfortable with. It is the process by which code gets merged into the baseline that I'm interested in. I figured working on a documentation tool would be a good way to get started. |
tools/doc/html.js
Outdated
@@ -24,6 +24,11 @@ | |||
const common = require('./common.js'); | |||
const fs = require('fs'); | |||
const marked = require('marked'); | |||
var unified = require('unified'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
const
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed and squashed.
515edb5
to
9b5344b
Compare
From within
I'm going to add the If we can get all the code changes in that would result in |
Unlikely at this point as I have only added dependencies so far. Removing comes later.
Please explain?
Cool.
It is possible that I will be able to complete this tomorrow, but if not I don't expect to have much time Monday through Wednesday, but I should be able to wrap this up by next weekend. I'm happiest if changes are merged incrementally, but that may be asking a lot. I will say that this change should be easy to revert should it come to that. If not, should I have separate branches, or a single branch for the total set of changes? |
Nevermind. Looks straightforward enough. |
deleted: tools/doc/node_modules/define-properties/.editorconfig
deleted: tools/doc/node_modules/define-properties/.eslintrc
deleted: tools/doc/node_modules/define-properties/.jscs.json
deleted: tools/doc/node_modules/define-properties/.npmignore
deleted: tools/doc/node_modules/define-properties/.travis.yml
deleted: tools/doc/node_modules/define-properties/CHANGELOG.md
deleted: tools/doc/node_modules/define-properties/test/index.js
deleted: tools/doc/node_modules/extend/.eslintrc
deleted: tools/doc/node_modules/extend/.jscs.json
deleted: tools/doc/node_modules/extend/.npmignore
deleted: tools/doc/node_modules/extend/.travis.yml
deleted: tools/doc/node_modules/extend/CHANGELOG.md
deleted: tools/doc/node_modules/extend/component.json
deleted: tools/doc/node_modules/foreach/.npmignore
deleted: tools/doc/node_modules/foreach/component.json
deleted: tools/doc/node_modules/foreach/test.js
deleted: tools/doc/node_modules/is-nan/.eslintrc
deleted: tools/doc/node_modules/is-nan/.jscs.json
deleted: tools/doc/node_modules/is-nan/.npmignore
deleted: tools/doc/node_modules/is-nan/.travis.yml
deleted: tools/doc/node_modules/is-nan/CHANGELOG.md
deleted: tools/doc/node_modules/is-nan/test/index.js
deleted: tools/doc/node_modules/is-nan/test/shimmed.js
deleted: tools/doc/node_modules/is-nan/test/tests.js
deleted: tools/doc/node_modules/kebab-case/.editorconfig
deleted: tools/doc/node_modules/kebab-case/.npmignore
deleted: tools/doc/node_modules/kebab-case/.travis.yml
deleted: tools/doc/node_modules/kebab-case/test.js
deleted: tools/doc/node_modules/marked/.npmignore
deleted: tools/doc/node_modules/marked/.travis.yml
deleted: tools/doc/node_modules/marked/Gulpfile.js
deleted: tools/doc/node_modules/marked/bower.json
deleted: tools/doc/node_modules/marked/component.json
deleted: tools/doc/node_modules/marked/doc/broken.md
deleted: tools/doc/node_modules/marked/doc/todo.md
deleted: tools/doc/node_modules/mdurl/CHANGELOG.md
deleted: tools/doc/node_modules/object-keys/.editorconfig
deleted: tools/doc/node_modules/object-keys/.eslintrc
deleted: tools/doc/node_modules/object-keys/.jscs.json
deleted: tools/doc/node_modules/object-keys/.travis.yml
deleted: tools/doc/node_modules/object-keys/CHANGELOG.md
deleted: tools/doc/node_modules/object-keys/test/index.js
deleted: tools/doc/node_modules/trim/.npmignore
deleted: tools/doc/node_modules/trim/History.md
deleted: tools/doc/node_modules/trim/component.json
deleted: tools/doc/node_modules/x-is-array/.npmignore
deleted: tools/doc/node_modules/x-is-array/.travis.yml
deleted: tools/doc/node_modules/x-is-array/test/index.js
deleted: tools/doc/node_modules/x-is-string/.npmignore
deleted: tools/doc/node_modules/x-is-string/.travis.yml
deleted: tools/doc/node_modules/x-is-string/test/index.js
deleted: tools/doc/node_modules/xtend/.jshintrc
deleted: tools/doc/node_modules/xtend/.npmignore
deleted: tools/doc/node_modules/xtend/test.js |
Do it at whatever pace suits you. Having just one markdown processor in our dependencies is a nice-to-have for sure, but there's certainly no deadline or anything. Also, be aware that there's always the chance it won't get merged. There may be reasons for using
Maybe one PR/branch but multiple atomic/incremental commits? Just as long as every commit contains a fully working system. No commit should be broken, of course. |
tools/doc/html.js
Outdated
@@ -36,13 +41,31 @@ marked.setOptions({ renderer }); | |||
|
|||
const docPath = path.resolve(__dirname, '..', '..', 'doc'); | |||
|
|||
// add class attributes to index navigation links |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We usually use a first uppercase letter and a period in the end in comments lately)
// Add class attributes to index navigation links.
I've checked the diff between the results of this PR and the current master and it seems we have no significant changes so far, just these nits:
|
Is there a way to reuse the remark modules that are already included in our source tree? |
Hit a speed bump. I've converted the code to the point where HTML is produced that resembles the input (always a good sign!) for all but one of the files. That file is A small test case: https://gist.github.com/rubys/a061064e0744a5792b3e8331b0dae37d The file in question is 52K lines. The problem is the size - processing either the first 26K or the last 26K lines works just fine. Possible solutions include increasing the heap size; processing this one file in chunks, building this file using other means, or aborting this effort. |
BTW, |
There appears to be very few LICENSE files in the node_modules themselves:
|
This is fantastic so far. Thanks for getting it moving so far so fast. I don't know what the right answer is to the 52K-line heap-exhaustion dilemma, but processing it in chunks seems like a promising idea given that the |
It seems the cause of the issue is a collision between link references: now we join sources first and then parse/convert them, so all homonymous links are rewritten by the last one. If we could parse/convert the sources first and then join them, the issue may be fixed. |
@vsemozhetbyt perhaps something like this: https://gist.github.com/rubys/4a140b5b61eab4cea34aca56098e900e ? Seems to be able to handle the full document without running out of heap space. Perhaps it could be cleaned up and landed separately as a fix for #20100 . |
tools/doc/package.json
Outdated
@@ -7,7 +7,15 @@ | |||
"node": ">=6" | |||
}, | |||
"dependencies": { | |||
"marked": "^0.3.5" | |||
"jsdom": "^11.11.0", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this dependency intended for this PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch! Fixed.
What we also need to estimate is doc building time with various toolchains, as doc building is run on each CI and local tests. Currently on my machine, real 0m46.983s
real 1m32.970s I.e. this approach is twice as slow. If we use it also for JSON generation, it can be three times as slow. However, it can be faster (or slower) with another |
Some performance data: { gtoc: 31,
parse: 207,
firstHeader: 1,
preprocessText: 8,
preprocessElements: 131,
buildToc: 46,
remark2rehype: 26,
raw: 262,
serialize: 41 } See https://gist.github.com/rubys/4798e9c5418814c8810b295dfb5cbbaa for how I instrumented the code. Here's the command I used:
I picked The biggest times are for parsing HTML ( I haven't looked closely at the JSON processing yet, but given that there is but a single occurrence of This one change won't eliminate the time difference between marked and remark tool chains, but would significantly reduce it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've only started to learn the toolchain and the new html.js
, so this is just some nits so far) I will continue on Saturday if I find some more time)
tools/doc/html.js
Outdated
function navClasses() { | ||
return walker; | ||
|
||
function walker(node, file) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As we do not use the file
argument, maybe we can drop it here and in the recursive calls?
tools/doc/html.js
Outdated
.use(markdown) | ||
.use(firstHeader) | ||
.use(preprocessText) | ||
.use(preprocessElements, { filename: filename }) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just { filename }
here and below?
tools/doc/html.js
Outdated
.replace(/__VERSION__/g, nodeVersion) | ||
.replace('__TOC__', toc) | ||
.replace('__TOC__', content.toc) | ||
.replace('__CONTENT__', content.toString()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure if this is significant, but is it worth to make this change at the very end? We have some replacing below, and content.toString()
is the biggest insertion here. Would the __GTOC__
, analytics
and docCreated
insertions be faster if it is made before __CONTENT__
replacement? Because this will make .replace()
calls operate on a smaller string.
If #21568 is incorporated, I'll clean up and complete this pull request (for example, the increase in heap size can be removed). I'd rather wait on the JSON generation until a decision is made on remark vs marked, but if this one is approved, I will start on the JSON conversion. |
Should the |
PR-URL: nodejs#21490 Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com>
|
I'll try to clean it up as a part of #21697, which is now unblocked. |
This comment has been minimized.
This comment has been minimized.
Markdown interprets the syntax for optional arguments as a form of a link, so instead of trying to build up the contents using the node value, use grab the raw original markup instead. Fixes regression noted in nodejs#21490 (comment)
Markdown interprets the syntax for optional arguments as a form of a link, so instead of trying to build up the contents using the node value, use grab the raw original markup instead. Fixes regression noted in #21490 (comment) PR-URL: #21922 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com>
PR-URL: #21490 Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com>
Markdown interprets the syntax for optional arguments as a form of a link, so instead of trying to build up the contents using the node value, use grab the raw original markup instead. Fixes regression noted in #21490 (comment) PR-URL: #21922 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com>
@rubys Another breaking change: in headings, some optional arguments are linkified and next arguments disappear. Compare, for example, this doc heading before this PR landed and in the last Nightly (the last one is after the #21922 has been landed so that PR has not fixed this issue). |
ensure optional parameters are not treated as markedown links by replacing the children of headers nodes with a single text node containing the raw markup; Fixes issue identified in nodejs#21490 (comment)
ensure optional parameters are not treated as markedown links by replacing the children of headers nodes with a single text node containing the raw markup; Fixes issue identified in #21490 (comment) PR-URL: #21936 Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com> Reviewed-By: Minwoo Jung <minwoo@nodesource.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
ensure optional parameters are not treated as markedown links by replacing the children of headers nodes with a single text node containing the raw markup; Fixes issue identified in #21490 (comment) PR-URL: #21936 Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com> Reviewed-By: Minwoo Jung <minwoo@nodesource.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
* remove obsolete `node_modules/js-yaml/package.json` target * remove `@touch` since `npm ci` is always destructive PR-URL: nodejs#22399 Refs: nodejs#21802 Refs: nodejs#21490 Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com> Reviewed-By: Sam Ruby <rubys@intertwingly.net> Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Daijiro Wachi <daijiro.wachi@gmail.com>
* remove obsolete `node_modules/js-yaml/package.json` target * remove `@touch` since `npm ci` is always destructive PR-URL: #22399 Refs: #21802 Refs: #21490 Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com> Reviewed-By: Sam Ruby <rubys@intertwingly.net> Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Daijiro Wachi <daijiro.wachi@gmail.com>
* remove obsolete `node_modules/js-yaml/package.json` target * remove `@touch` since `npm ci` is always destructive PR-URL: #22399 Refs: #21802 Refs: #21490 Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com> Reviewed-By: Sam Ruby <rubys@intertwingly.net> Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Daijiro Wachi <daijiro.wachi@gmail.com>
First baby step towards implementing #21476
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes