perf(mdx-loader): cache mdx/remark compiler instances - #4997
Conversation
|
Hi @phryneas! Thank you for your pull request and welcome to our community. Action RequiredIn order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you. ProcessIn order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA. Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with If you have received this in error or have any questions, please contact us at cla@fb.com. Thanks! |
|
Hmm. Seems like this would need I have |
|
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks! |
|
I guess you should try fetching upstream first, since it seems your branch is quite old... In the lastest master I see |
|
Damn, I could have sworn I checked out the docusaurus repo for the first time in my life yesterday! |
# Conflicts: # packages/docusaurus-mdx-loader/src/index.js
There was a problem hiding this comment.
Updated the PR
That looks like a nice idea overall, but I'm not sure it would work in the current form, as each cached compiler will capture the first filepath being compiled.
Maybe there's a way for a remark plugin to access current file path being processed, without passing it through options?
We can see the problem in practice by building the Docusaurus site:
3:45:39 PM: Error: Image ../assets/docusaurus-asset-example-banner.png used in docs/presets.md not found.
3:45:39 PM: at async Promise.all (index 0)
This image is not used in docs/preset.md, but in docs/guides/markdown-features/markdown-features-assets.mdx
| ...DEFAULT_OPTIONS.remarkPlugins, | ||
| [ | ||
| transformImage, | ||
| {staticDir: reqOptions.staticDir, filePath: this.resourcePath}, |
There was a problem hiding this comment.
Using this.resourcePath here makes me think this PR is not good enough.
Our remark plugins need to be able to access current file path to check if relative image/asset links are valid etc.
There was a problem hiding this comment.
Apparently we may be able to access it thanks to the transform(node,vfile) and vfile.history[0]: https://github.com/vfile/vfile#vfilehistory
Will see how to refactor the PR with it
There was a problem hiding this comment.
Yeah, I just took another look at https://github.com/mdx-js/mdx/pull/1468/files and they completely removed the filePath: this.resourcePath from the options object and only used it as parameter in the second argument of compiler.process - so it seems to be the accepted standard way to use that instead of accessing filePath from the options object.
|
@slorber Let's try to get this merged for the 2.0 release as well. I personally don't know much about Webpack / Remark file resolution and it seems you have a solution in mind? |
Josh-Cena
left a comment
There was a problem hiding this comment.
Nice, vfile fixes it!
✅ [V2]Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site settings. |
|
⚡️ Lighthouse report for the changes in this PR:
Lighthouse ran on https://deploy-preview-4997--docusaurus-2.netlify.app/ |
There was a problem hiding this comment.
This PR looks fine but this leads to a ton of new warnings in our case:
https://app.netlify.com/sites/docusaurus-2/deploys/61e9239e50d8f50008ce297d
Those are not brand new warnings apparently, also in prod:
It just became more visible now since we create like 16 MDX compilers due to all of our plugin instances.
I think we should try to fix these warnings first before merging this PR.
It might be warnings that only us have, due to some docs 🤷♂️ but let's figure this out
|
Mmm, true. Last time I inspected I didn't find anything useful about where we were missing these imports. Probably one in the deployment doc. I'm actually surprised that this creates more warnings than before. I guess it's because every call to |
|
Okay, this problem is once again caused by the MDX infrastructure not present during blog feed generation 😅 Should be fixed by #6454 |
Nop, there were some missing Tab/TabItem imports that I fixed Also we have an issue with the npm2yarn plugin, not sure why we only see this now. The warning could as well be related to upgrading MDX and we didn't notice. As it's very verbose I'd rather get this fixed before we merge the PR |
I suppose you are talking about the npm2yarn plugin automatically importing Tabs if they are not present? That seems to be the case for both files you fixed? |
I didn't have time to investigate much, I just know that removing the remark plugin removes the warnings |
|
Took a look and found the issue. It's because the npm2yarn plugin wrongly put the state outside the transformer, so it would share the same state across different MDX files, and cause later files to not have |
|
Going to merge now! The behavior seems good. I have made sure we don't have stateful logic outside the transformer anywhere else, so caching shouldn't affect most users. |
|
Thanks 👍 |
* (mdx-loader) only create mdx compiler once per webpack config * type fixes * fix path * remove assertion * docs: add missing Tab/TabItem imports * fixup Co-authored-by: slorber <lorber.sebastien@gmail.com> Co-authored-by: Josh-Cena <sidachen2003@gmail.com>


Motivation
Fix #4978
With this change, a new mdx compiler will be created once per webpack config instead of once per config AND file. This can have a massive impact as for example in the case of https://github.com/phryneas/remark-typescript-tools where every instantiation of the compiler also meant an instantiation of the remark plugin and hence a new instance of the TypeScript compiler.
A very similar change has been made over in the mdx-loader in https://github.com/mdx-js/mdx/pull/1468/files and you can compare the introduced changes with the original
compileimplementation over at https://github.com/mdx-js/mdx/blob/907bd26d83287180c7155c0fb65671b7cb55c98d/packages/mdx/index.js#L44-L47Have you read the Contributing Guidelines on pull requests?
Yes.
Test Plan
This brings memory consumption of the redux-toolkit docs with my plugin (without workarounds) down from about 6GB to 2.8GB, while the plugin with workarounds comes down to 2.4GB (as that shares the compiler instance between the server and client config, but I erred on the more secure side with this PR and kept those separate).