-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Attempt to enable inclusion of partial markdown #227
Conversation
fff62f3
to
4416673
Compare
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.
LGTM, only some small things.
lib/webpack/util.js
Outdated
const deps = [] | ||
|
||
return { | ||
explodedSrc: src.replace(/<!-- *include +(.*?) *-->/g, (match, path) => { |
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.
Using <!--\s*include\s+([^\s]+)\s*-->
or <!-- include -->
will be matched
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 idea. 🎉
lib/webpack/util.js
Outdated
explodedSrc: src.replace(/<!-- *include +(.*?) *-->/g, (match, path) => { | ||
try { | ||
const absolutePath = resolve(cwd, path) | ||
const content = readFileSync(absolutePath, 'utf8') |
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.
Using a unified convention at the same project. either that all are await readFile
or all are readFileSync
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 have made this loader asynchronous. And it took me a really really long time to complete the asyncReplace
function. I am so glad that I did this in such an elegant way.
Also it took me really long to debug the async loader as I forgot to call the callback when the loader hit the cache. 😭
Anyhow, it is using readFile now.
lib/webpack/markdownLoader.js
Outdated
|
||
const cache = LRU({ max: 1000 }) | ||
const devCache = LRU({ max: 1000 }) | ||
|
||
module.exports = function (src) { | ||
const file = this.resourcePath | ||
const cwd = path.dirname(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.
just leverage dir
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.
Can you explain more on this?
lib/webpack/util.js
Outdated
@@ -0,0 +1,49 @@ | |||
const { promisify } = require('util') |
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.
You can use fs-extra
here without having to promisify
.
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.
Oh, didn't know it exists. I will do this now.
@yyx990803 @ulivz Do you guys think those are big concerns? Furthermore, one more thing to consider, should we force every partial to end with |
199f99e
to
d1c0da8
Compare
d1c0da8
to
961eada
Compare
lib/webpack/markdownLoader.js
Outdated
module.exports = async function (src) { | ||
const cb = this.async() | ||
try { | ||
/* IMPORTANT: I didn't indent these lines to hopefully get a better looking diff */ |
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 have un-indented the lines in the try { ... } catch
block to show a better looking diff. Please re-indent when PR is accepted. 😊
Regarding the caching problem, after some think about it, it is probably not a problem because a partial is expected to be part of a longer markdown, therefore each partial should be included only once. 🌮 |
Any idea on when this is going to be released? I'm working on a team that could really use this functionality. |
@kevinmpowell Hopefully this will get released in 1.0. |
51da635
to
63d755e
Compare
c992e38
to
c2eaff3
Compare
0c3bc3a
to
cf1e6fc
Compare
@davemacdo @MartinMuzatko
But I guess I will not make the changes to this PR unless @ulivz agree to it. 👍 |
bd69d41
to
903138e
Compare
Out of curiosity - how would partial markdown files work in regards to front-matter. Would each partial share access to the parent markdown's front-matter, or would each partial have its own front-matter? I like the latter, because then it would be possible to have a separate markdown file for each method in package documentation, such that it is possible to define (in the each partial's front matter) the method name, parameter names and types, return names and types, etc, then render to an automated vue component. This would make for much cleaner and easier to read documentation code that could then also be automatically parsed from raw code, e.g. python docstrings, into markdown docs... |
3f79224
to
fb05066
Compare
6c3127f
to
71574f2
Compare
316e022
to
1284944
Compare
Any progress on this? |
Since there is a similar syntax already to include code snippets which is
it would be nice to have something similar to include markdown files. But since v1 is not stable yet this can also be changed later (in another PR), right? In general I like the approach of using a syntax which works when the markdown is rendered also on GitHub. It allows really easy contribution. Here is an example:
The syntax they use is:
related: #1474 |
Does the current implementation allow to include markdown files which itself have references to other resources, like links to other markdown files and images (or even nested includes)? |
We can use the markdown-it-include plugin to achieve this. The only issue is the rebuild process. I have opened an issue here |
I have attempted to add this functionality as discussed in #222.
Current implementation facilitates the below functionality:
<!-- include ./path/to/my/file.md -->
with the content of the file (recursively)There are currently 2 known problems in this implementation:
mdExplodeIncludes()
<!-- include PATH -->
could not be escaped even in code block. IfPATH
is an actual file, the file content would be used. This behaviour might not be desirable in some occasion. (e.g. when I was documenting about this functionality.)