Motivation

In MDX loader, we previously serialized metadata:

export const metadata = ${JSON.stringify(metadataObject)}`;

Now we do import and re-export the existing module:

export {default as metadata} from '@site/.docusaurus/..../x-metadata-module.json';

Note: in our content plugins, we created the JSON module only to read it later from the MDX loader:

// blog
      await createData(
        // Note that this created data path must be in sync with
        // metadataPath provided to mdx-loader.
        `${docuHash(metadata.source)}.json`,
        metadata,
      );

// docs
      await actions.createData(
        // Note that this created data path must be in sync with
        // metadataPath provided to mdx-loader.
        `${docuHash(doc.source)}.json`,
        doc,
      );

This was quite useless since we already had that data in memory. This has been changed in #10457 by reading from memory instead of JSON.

After this optimization, a question remained: What's the purpose of this JSON bundle? Now it has a purpose: it will be imported/re-exported by the MDX loader.

This has benefits for the blog because the same blog post is being rendered in 2 variants: full and truncated. Now instead of duplicating blog metadata in both versions, the bundler will not duplicate and the 2 variants can share the same metadata module.

Impact

This doesn't have a significant impact on bundle time, despite partially reverting #10457. Now Webpack will read a JSON file from the filesystem instead of from memory, but for blog posts it will only include it once and reduce emitted JS size.

But it does have an impact on the JS size of a site since blog metadata are not duplicated anymore:

BEFORE

• build: 142.4 Mo
• server bundle: 15.8 Mo + 8.5 chunks

AFTER:

• build: 141.7 Mo
• server bundle: 15.1 Mo + 8.5 chunks

Test Plan

CI

Test links

https://deploy-preview-10470--docusaurus-2.netlify.app/