Devdocs: Use Webpack Loader to load READMEs

[ockham]

Preparation for #35809.
Merge #36167 before this PR.

I think this is in the spirit of the previous architecture, but leverages modern technologies better: We continue to load and render those individual READMEs, and can even serve them over the network, thanks to Webpack's lazy loading feature.

Changes proposed in this Pull Request

• Install markdown-loader, and use it to load .md files

Testing instructions

• Go to http://calypso.localhost:3000/devdocs/design/button, and verify that the README is rendered correctly at the bottom of the page (compare to https://wpcalypso.wordpress.com/devdocs/design/button).
• Verify that other devdocs links in the sidebar, such as http://calypso.localhost:3000/devdocs/docs/guide/index.md, also still work.

TODO

Fix http://calypso.localhost:3000/devdocs/.github/CONTRIBUTING.md. Probably broken because of the hidden .github directory 🙁
Update: Looks like we might be able to just move it to docs/ and it'll still be used by GitHub! 🎉

To help your project contributors do good work, you can add a file with contribution guidelines to your project repository's root, docs, or .github folder. When someone opens a pull request or creates an issue, they will see a link to that file.

(Source)

I guess I'll file a separate PR. Update: #36167

[matticbot]

Test live: https://calypso.live/?branch=update/readme-viewer-use-webpack-loader

[matticbot]

Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:

Webpack Runtime (~36161 bytes added 📈 [gzipped])

name      parsed_size            gzip_size
manifest     +52563 B  (+31.4%)   +36161 B  (+120.0%)

Webpack runtime for loading modules. It is included in the HTML page as an inline script. Is downloaded and parsed every time the app is loaded.

Sections (~8774 bytes added 📈 [gzipped])

name     parsed_size            gzip_size
devdocs     +62134 B  (+48.0%)    +8774 B  (+24.4%)

Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to.

Async-loaded Components (~2 bytes removed 📉 [gzipped])

name                          parsed_size           gzip_size
async-load-design-blocks            -24 B  (-0.0%)       +0 B
async-load-design                   -24 B  (-0.0%)       -1 B  (-0.0%)
async-load-design-playground        -16 B  (-0.0%)       -1 B  (-0.0%)

React components that are loaded lazily, when a certain part of UI is displayed for the first time.

Legend

What is parsed and gzip size?

Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory.
Gzip Size: Compressed size of the JS and CSS files. This much data needs to be downloaded over network.

Generated by performance advisor bot at iscalypsofastyet.com.

[ockham]

#36167 should hopefully unblock this

[sirreal]

Builds seem to be failing on calypso.live and CircleCI. @ockham have you looked at those?

[blowery]

Adding 36k of zipped js to the manifest, which is inlined in each entrypoint, probably isn't ideal. Is that actually happening, or is that a reporting ghost?

[jsnajdr]

Adding 36k of zipped js to the manifest, which is inlined in each entrypoint, probably isn't ideal. Is that actually happening, or is that a reporting ghost?

Yes, that really happens, because we have plenty of new webpack chunks for each README file. Good argument for making devdocs a completely separate app with its own webpack build and chunk structure.

Separate entrypoint is not enough, as all entrypoints share the manifest and they all influence the shared chunks optimization.

[blowery]

Separate entrypoint is not enough, as all entrypoints share the manifest and they all influence the shared chunks optimization.

We can split up the manifests per entrypoint, which might buy us some time... Doesn't break apart the optimization of chunk splits though.

[jsnajdr]

@ockham I'm proposing a different solution in #38784. It also removes the need for filesystem access into the source tree at runtime, but achieves the goal very differently.

[ockham]

Closing in favor of #38784.