Add info on how to extend webpack.config.js

[mor10]

See #14560 for background

Description

Adds explanation and code example for how to extend webpack.config.js using spread operator.

Types of changes

Documentation update.

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.

[gziolo]

On a different note, I was looking into https://github.com/smooth-code/svgr and I wasn't aware it has so many useful packages in addition to CLI tool and webpack loader. It makes me wonder if we shouldn't redefine the way we handle SVG icons and maybe start using files with SVGs and tackle them with custom Babel loader which would convert them to React components on the fly providing a unified format with both React web and React Native can process.

[gziolo]

There is related chat in core-js WordPress Slack channel (link requires registration at https://make.wordpress.org/chat/):
https://wordpress.slack.com/archives/C5UNMSU4R/p1553509272322700

I think it's fine to include this note, we might need to rephrase it to ensure that people are aware that doing so they can run into compatibility issues when the default config changes because of WordPress needs or when webpack changes API.

[mkaz]

With @nosolosw suggestion this looks good to go

[mor10]

@gziolo I would back the inclusion of SVGR 100%. It makes adding and using SVGs in blocks significantly easier and removes the need for custom workarounds. Here's how I'm using it to add a block logo as a React component:

import customLogoURL, { ReactComponent as customLogo } from "./logo.svg";

registerBlockType("block/myblock", {
  title: __("A Block", "myblocs"),
  icon: {
    src: customLogo // The React component
  },
  category: "regular",
  attributes: {
    blockImage: {
      type: "string",
      default: customLogoURL // The URL to the original SVG
    }
  },
  (...)
}

[gziolo]

I would back the inclusion of SVGR 100%. It makes adding and using SVGs in blocks significantly easier and removes the need for custom workarounds.

Thanks for sharing. I opened a follow-up issue to keep what you shared documented (#14628).

[isvictorious]

Any examples of adding support for SCSS?

[gziolo]

Any examples of adding support for SCSS?

In #13814 I listed a few webpack configs from WordPress plugins:

• Gutenberg SlotFill and Filter demos by @ryanwelcher
• Juxtapose Block by @mkaz
• Gutenberg Custom Fields by @youknowriad
• Gutenberg Extensibility Workshop by @youknowriad
• Drop it by @youknowriad
• Tomodomo Block Starter by @chrisvanpatten

You might find there an example of how to handle SCSS. We don't use webpack to handle SCSS files in Gutenberg. However, this might be a good idea to include such capability in wp-scripts start and wp-scripts build.

I think I also saw SASS integration in create-cloud-block (A boilerplate generator for building Gutenberg Cloud blocks to use with Drupal and WordPress):
https://github.com/front/create-cloud-block/blob/master/examples/1-simple-block/webpack.config.js

[fabiankaegy]

@isvictorious I played around with it some and this is what I am currently using to extend the config to use scss compiling

https://github.com/fabiankaegy/callout-block/blob/extending-wp-scripts-scss/webpack.config.js

[gziolo]

@fabiankaegy - it looks reasonable as far as I can tell. In Gutenberg there is also this file:
https://github.com/WordPress/gutenberg/blob/master/packages/block-library/src/theme.scss

I don't remember what role it plays, but it might be worth to double check if you would need it as well.

[isvictorious]

@gziolo @fabiankaegy thanks for sharing. As we build more and more blocks I am trying to avoid dependency management as much as possible. @wordpress/scripts has most of what we need (testing, babel, etc) except Sass.

A big issue going forward with custom blocks is going to be dependency management.

[mor10]

Counterpoint: Sass is falling out of favor fast in the wider web community for good reason: between custom properties and nesting as native CSS features, and PostCSS doing everything Sass can do and more, Sass is seen to stand in the way of progress. I would recommend setting up a PostCSS config instead.

[gziolo]

@fabiankaegy, thanks for opening an issue, let's continue the discussion there 👍