Guides - Annotated Walkthrough of Output

[TheLarkInn]

This idea popped into my head from this tweet.

We should display a simple bundle which uses different types of Deps (AMD, CommonJS, Harmony), and then a top to bottom annotated walkthrough of what each part of the code is doing and why.

Would be a cool way for people to get the basic anatomy of the bundle, normal chunks, initial chunks, entry chunks, and understand what is really happening when code splitting occurs.

[rouzbeh84]

Any movement on this? I could probably rework the below into something less fun but clearer haha

cc: @TheLarkInn @skipjack

[TheLarkInn]

That might be a good place to start actually. And using even a single example would be awesome. I've even been pondering maybe a complex svg animation that shows the entire process. Just a lot of work involved heh.

[skipjack]

@rouzbeh84 if you wanted to pick this up that would be great! Maybe stem from one of the simpler guides and just walk through the different bits of the output bundle?

I've even been pondering maybe a complex svg animation that shows the entire process. Just a lot of work involved heh.

@TheLarkInn maybe we could just start with a simple mermaid graph like the others created in #469?

[skipjack]

From what I saw while inspecting a bundle in my work on the Tree Shaking guide in #1508, it seems the comments within bundles have gotten much better since when I first started using webpack. These comments are stripped out when the UglifyJSPlugin is included obviously, but a non-minified bundle could actually be fairly intuitive to go through. Maybe the guide could just jump through the bundle based on the comments and elaborate on each section.

[skipjack]

Ok I'm going to close for a few reasons...

• It's been inactive for a while now.
• The output is actually a lot cleaner than it used to be and has pretty descriptive comments.
• The output changes frequently with new releases so the guide may become outdated fairly quick.
• Better to clean up and revise existing content before adding whole new articles.

With all that said, if someone disagrees with the points above, wants to re-open this, has the time to tackle it so it doesn't remain stagnant then I'm open to it. For the outdated reason above I do think this article may make more sense as a blog post than core documentation.

[skipjack]

Also marked with the reconsider label so once we're done with the reviews and infrastructure cleanup we could easily consider revisiting this.