[docs] Use custom webpack loader for markdown

[eps1lon]

Problem: Previous usage of require-context with inline loaders is no longer supported in webpack 5 (webpack/webpack#12900)
Solution: Replace with a single import + custom loader that fakes require.context

Preview: https://deploy-preview-26774--material-ui.netlify.app/components/tables/

Ignore 1a6775e since this is just the change from using npx @codemod/cli docs/pages --remote-plugin https://astexplorer.net/#/gist/5a4cf1d9e15657695ae270f5c7819b2c/2e489edc6b0014506602f34c069d6428b448e1e5 (https://astexplorer.net/#/gist/5a4cf1d9e15657695ae270f5c7819b2c/2e489edc6b0014506602f34c069d6428b448e1e5)

Additional benefits:

1. parsing markdown at compile time
2. less boilerplate in the docs pages (at the cost of magically creating variables via loader)
3. Enables Import markdown components on demand (e.g ComponentLinkHeader is always imported in MarkdownDocs even though it might now be used. The code is not tree-shakeable at the moment)
4. hot reloading of markdown (getInitialProps did not automatically update the page when markdown changed)

Isn't this tying us more to webpack?
Just as much as we were tied before since require.context is webpack specific.

TODO:

• convert to async loader
• apply to all require.context('!raw-loader!') usages
• render markdown directly in the loader

Follow-Up:

• Remove requireRaw mock (needs work in prepareMarkdown)
• Import markdown components (like ComponentLinkHeader) on demand

[mui-pr-bot]

No bundle size changes (experimental)

Generated by 🚫 dangerJS against 8ab8bec

[oliviertassinari]

As a side note, we broke HMR support for the markdown of the page a while ago. I don't think that this change will help or harm this aspect, I'm only raising it as it's may be relevant in the future.

Is reading the markdown on its editor good enough? I don't think so, nor that it's close to good enough. HMR of the markdown allows to work on the actual content developers will see when consuming the content. Losing sight of this is a good way to write markdown that looks OK on its editor but KO once rendered (e.g. title too long to fit, wrong code indentation, overwhelming code sections, etc.). I personally frequently reload the page (it's slower), to make sure it's OK, as I work on the content. It would be interesting to see if other contributors have the same frustration.

[eps1lon]

Yep that's a problem. But it improves user experience by a lot which is more important. For live reloading of markdown you could always use the preview in your code editor (vscode has this built-int).

[eps1lon]

Makes more sense to move rendering markdown to the loader in this PR as well. Some pages don't follow the pages/somePage <-> src/pages/somePage mapping. The follow-up would be just as big and these concerns are tightly coupled anyway.

[eps1lon]

I don't think that this change will help or harm this aspect, I'm only raising it as it's may be relevant in the future.

Pushed "render markdown at bundle time" to make it clearer that hot reloading is going to be improved. Changes to parseMarkdown will not trigger hot-reloading but changing the markdown content will.

[eps1lon]

Has been open for a while. Will merge after the updating the branch and then we'll see if we discover any problems.

[oliviertassinari]

I'm taking care of it #26970.

[oliviertassinari]

@eps1lon It looks pretty cool! 💯 for the HMR of the markdown. I hold on to the release because I wanted to try dynamic pages with Next.js, and see how this change fits into the equation, but I didn't get the time, so it's fine.

Why do I mean by dynamic page? It seems inefficient to build each API page (>100) when it always renders the same type of content. So my thought was: why don't we create one dynamic /api page. This way, we can build it once, saving x minutes (to be measured) of builds and dynamically render the .json of the different components. We didn't touch the API pages, so 🙆‍♂️

[oliviertassinari]

The changes seem to have broken the docs in development on Windows: #21053 (comment).