Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add info on how to extend webpack.config.js #14590

Merged
merged 2 commits into from
Mar 25, 2019
Merged

Conversation

mor10
Copy link
Contributor

@mor10 mor10 commented Mar 22, 2019

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.

 See WordPress#14560. Adds explanation and code example for how to extend `webpack.config.js` using `spread` operator.
@gziolo
Copy link
Member

gziolo commented Mar 25, 2019

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
Copy link
Member

gziolo commented Mar 25, 2019

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.

Copy link
Member

@mkaz mkaz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With @nosolosw suggestion this looks good to go

Co-Authored-By: mor10 <morten@pinkandyellow.com>
@mkaz mkaz merged commit d718a97 into WordPress:master Mar 25, 2019
@mor10
Copy link
Contributor Author

mor10 commented Mar 25, 2019

@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
Copy link
Member

gziolo commented Mar 26, 2019

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
Copy link

Any examples of adding support for SCSS?

@gziolo
Copy link
Member

gziolo commented Apr 3, 2019

Any examples of adding support for SCSS?

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

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
Copy link
Member

@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
Copy link
Member

gziolo commented Apr 3, 2019

@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
Copy link

@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
Copy link
Contributor Author

mor10 commented Apr 3, 2019

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
Copy link
Member

gziolo commented Apr 4, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Tool] WP Scripts /packages/scripts [Type] Developer Documentation Documentation for developers
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants