Revisit build process

[toddmilliken]

Background

As I was fixing an issue noted by autoprefixer with the linear-gradient syntax in version 3.2.3, @ashleykolodziej had noted that there was some concerns that compile time from sass => css was taking awhile. We troubleshooted this down to postcss process being run on both the css minified file and the non-minified css file. This could be quickly remedied by running postcss once on the non-compiled file, and then minifying it through something like uglify. But then we started talking about revisiting our build process in general.

The following is a list of notes that came out of a meeting on 10/11/19 to revisit our build process needs. We discussed several potential avenues:

• npm scripts (no extra dependencies. may be slower? straight forward)
  • Example: https://www.studio4130.com/wordpress-development-using-npm-scripts/
• @wordpress/scripts (sensible defaults, but no sass out-of-the-box)
  • Example: https://developer.wordpress.org/block-editor/packages/packages-scripts/
  • easier block development. webpack.
  • can be extended
  • seems to be made specifically for WP plugin development.
• webpack (advanced, running everything thru index.js and extracting assets out)
  • Example: https://carrieforde.com/webpack-wordpress/
• gulp workflow (definitely runs faster than grunt, but slightly more difficult/more js-driven)
  • Example: https://css-tricks.com/gulp-for-wordpress-initial-setup/
• grunt workflow (slowest, but easiest to configure).

Requirements for ideal build process

To help us make decisions, we came up with the following list of requirements:

• Must be able to compile sass => css
• es6/bundling capabilities for easier gutenberg/js development and maintenance

Other things to consider:

• We would need to setup kss, or some other alternative for styleguides
• Consider Dart Sass as a replacement to node-sass, as this is the primary implementation of Sass, which means it gets new features before any other implementation. However, compile times may be 25% longer (unless this has improved).
• Consider switching from browserify to webpack. Webpack seems to be used most in WP development at least in gutenberg. Not that there's anything wrong with browserify, but webpack may be more familiar to others.
• For the Framework theme, the phplint task could probably be done via composer. The current grunt-phplint library is not actively maintained and hasn't been updated in 3 years. Using composer could help unify the correct coding standard we want to apply to projects.
• Consider locking down browserslist on a project-by-project basis
• Run autoprefixer once, then minify.
• Potentially benchmark grunt vs gulp vs npm scripts
• Grunt is a wrapper around many core node packages, so we depend on grunt versions of these things to exist. By removing grunt, we may have more possibilities utilizing npm scripts. We seem to think npm scripts may be the way for maintenance purposes/simplicity, fewer dependencies/wrappers.

Next steps

We could make a branch off the latest Foundation develop branch, and start with npm scripts from scratch to get sass and webpack working, and then layer on kss. Most of the work involves the following processes:

• For sass, we need to a workflow like sass => css => postcss/autoprefixer => minified versions
• For js, we need a workflow like es6 => commonjs + es5 versions => minified versions. The reason we want both commonjs is so the bundles can be imported as a module into other repos as a dependency, and the es5 versions are for immediate browser-use if building directly on top of Foundation.