Webpack: Rewrite lesson with in-house tutorial (alongside ES6 Modules rewrite)

[MaoShizhong]

Because

The current Webpack lesson is a known pain point in the curriculum journey, primarily due to the sudden increase in complexity and steps of tooling, coupled with how much of the learning is left to external resources. These external resources limit the cohesiveness of teaching material, and can prove troublesome in the learning process when each resource includes a few unnecessary tidbits that can easily throw learners off (such as multiple entry points in the webpack official guides when learning about html-webpack-plugin). They also are frequently aimed at people who may know a little more about bundlers already, or are following a different course/tutorial. Thus, things often feel disjointed with the TOP curriculum.

While improving the Webpack lesson itself is the primary focus, it was also identified that the preceding ES6 modules lesson is fairly coupled with it, as Webpack and bundlers are introduced there instead of the Webpack lesson.

The order of the ES6 modules lesson was also identified as a little odd, and the order and flow could be improved by focusing on ES6 modules as a primary topic straight away, then introducing bundlers and Webpack in their own separate lesson.

General plan:

• Rewrite ES6 modules lesson
• Rewrite Webpack lesson
• Write new "Webpack revisited" lesson to go immediately after "Project: Restaurant Page".
  • Move more advanced but "convenience" topics there, like webpack-merge
  • Extract template repos section from "Linting" and place it here instead
• Tweak Project: Restaurant Page to reference any new material from preceding lesson changes if necessary

This PR

• Rewrites the current Webpack lesson (latest live preview)
• Amends the Restaurant Page project instructions to account for and reference the rewritten Webpack lesson

Issue

Related to #26976
Related to #26977
(closed by #27953)

Additional Information

This will be something to merge alongside 3 other PRs:

1. (ES6 Modules: Rewrite lesson (alongside separate PR for Webpack rewrite) #27953)
2. (Webpack: New second lesson after Project Restaurant Page #27962)
3. (Feature: Add new "Revisiting Webpack" lesson to both pathways theodinproject#4522)

Pull Request Requirements

• I have thoroughly read and understand The Odin Project curriculum contributing guide
• The title of this PR follows the location of change: brief description of change format, e.g. Intro to HTML and CSS lesson: Fix link text
• The Because section summarizes the reason for this PR
• The This PR section has a bullet point list describing the changes in this PR
• If this PR addresses an open issue, it is linked in the Issue section
• If any lesson files are included in this PR, they have been previewed with the Markdown preview tool to ensure it is formatted correctly
• If any lesson files are included in this PR, they follow the Layout Style Guide

[MaoShizhong]

Things I would like thoughts on in particular:

• Topics covered in this lesson, and the order they're covered
  • I've been debating exactly how to cover npm scripts, whether they'd be better at the end of the this lesson or at the start of the new second one, because the Webpack guide linked assigned in this lesson uses them throughout. My justification so far is that this lesson is mainly a custom in-house rewriting of the Webpack tutorial anyway, so the current note about npm run build in the assignment is sufficient, and npm scripts seem to be something we can leave for later to reduce overload.
• Quality and relevance of all aspects of the custom Webpack tutorial
  • The goal was to provide a similar tutorial that only includes the things that would be most relevant in our curriculum, as the Webpack one includes little bits like multiple entry points, runtime optimisations, devServer.static etc. that make sense for a general "here's how different parts of Webpack work", but less in the context of our curriculum.
  • An in-house tutorial would also allow us to explain the why behind certain configurations, as they'll often not explained well (if at all) in the Webpack guides. Such explanations often require some preexisting knowledge of bundlers and build tools.
  • Both of the above would allow us to steer learners more towards the happy path of setting up and using Webpack (and at least kinda getting it), while avoiding some of the main (and very very common) pitfalls we've noticed in the community. Oftentimes arising due to using things they don't need but don't realise, because they just copied the Webpack guide without reading side notes etc.
• Opinions on the removal of the npm script note for gh-pages deployment in the Restaurant Page project?
  • My justification is that npm scripts are going to be introduced properly in the new Revisiting Webpack lesson, so it would make sense to avoid bringing it up as a side thing before that point. It might also help reinforce the value of npm scripts after students "get annoyed" at potentially needing to copy and paste a long command each time they use it.

Any other aspects as well. The above is just what stuck around my mind most during writing.
@advait0603 tagging you here as well for whenever you get any time to review. Again, much of this was going off things you raised in the past and planned out.

[Advaitmenon1106]

Adding why templates are used in place of directly editing an html file in dist/ would be a good idea cause it would start a context for the advice- "not messing around with dist code".

https://discord.com/channels/505093832157691914/505093832157691916/1175351859343544380.....

...is a pretty good reference conversation and cleared my doubts about why dist/ is not modified by a developer.

[MaoShizhong]

This certainly can be reinforced. Given the perspective of someone going through this for the first time, do you think a reinforcement for HTML specifically is significantly valuable given that earlier in the lesson there's a section about src and dist? Which includes the following:

src is where we keep all of our website's source code, essentially where all of our work will be done (with an exception being altering any configuration files in the root of the project). When we run Webpack to bundle our code, it will output the bundled files into the dist directory. The idea is that if someone were to fork or clone the project, they would not need the dist directory, as they'd just be able to run Webpack to build from src into their own dist. Similarly, to deploy our website, we would only need the dist code and nothing else. Keep that in mind! Work inside src, build into dist, then deploy from there!

My idea was that this would be enough to justify not mentioning the HTML and dist thing, since it's already been introduced that all work goes in src, not dist. So I was thinking new learners might not even consider putting HTML in dist and working from there. But if you think this is still valuable to mention, then I can do so.