Challenge 2: Configuring Webpack for Both CSS and PNG Imports — Possible Solution
====================================================================

THE GENERAL APPROACH
------------------------------
Per this chapter's own loader material, Webpack needs a SEPARATE
loader RULE configured for each distinct file type the project wants
to import directly inside JavaScript — one rule matching .css files,
and a separate rule matching .png files, each pointing at the
appropriate loader(s) for that specific file type.

FOR .CSS FILES
------------------------------
Per this chapter's own webpack.config.js example, this would use a
rule matching files ending in .css, routed through css-loader (to
let JavaScript import CSS module content) and typically style-loader
as well (to actually inject the resulting styles into the page). The
rule would look conceptually like:

  { test: /\.css$/, use: ['style-loader', 'css-loader'] }

FOR .PNG FILES
------------------------------
Image files need their own separate rule matching .png (and typically
other image extensions), routed through an appropriate asset-handling
loader (in modern Webpack, this is often handled through Webpack's
built-in asset modules rather than a third-party loader, but the
underlying idea is identical): a rule that recognizes the .png
extension and tells Webpack how to include that file in the bundle
output (for example, emitting it as a separate file and giving
JavaScript a URL reference to it).

WHY TWO SEPARATE RULES ARE NEEDED
------------------------------
Per this chapter's own explanation, Webpack's dependency graph
natively only understands JavaScript's own import/require syntax —
it has no built-in understanding of what a .css file OR a .png file
actually means. Each file type needs its own dedicated rule
specifically because CSS and PNG files need to be handled in
completely different ways (CSS needs to become injectable
stylesheet content; a PNG needs to become a referenceable asset URL
or embedded data) — one loader configuration cannot serve both
purposes, so both rules must be present in module.rules
simultaneously for both kinds of import to work in the same project.

WHY THIS WORKS AS AN ANSWER
------------------------------
It applies the chapter's own rule-matching pattern to both file types
individually, explains what each file type's own loader actually
needs to accomplish, and explains why a single shared rule can't
serve both, rather than treating "add a loader" as one generic,
undifferentiated step.