Grunt + WordPress – make.wordpress.org – Trac Polishing



Grunt + WordPress – make.wordpress.org – Trac Polishing

0 0


grunt-presentation

For Web Dev Comm 3/10

On Github mgburns / grunt-presentation

Grunt + WordPress

Created by Mike Burns

Core Development Landscape

A quick look at recent improvements to WordPress development community.

Circa 2012

To those of you who don't follow WordPress core development every day, some quick background.

Just a few years ago if you were looking to get involved in WordPress development there were a few places to go:

WordPress.org - Home of WordPress - download the code, development blog and documentation at codex.wordpress.org. Audience - users self-hosting WordPress. core.svn.wordpress.org -- Point your SVN client here to download the bleeding edge release. Audience - developers, savvy-end users. unit-tests.svn.wordpress.org -- Test framework and test cases lived in separate repository. core.trac.wordpress.org -- Bug tracking using the Python-based Trac tool IRC - A few different channels, but #wordpress-dev is where the core devs hang out and meetings take place

Improvements since 2013...

A surge of activity in the past few months in lowing the barrier to entry for budding core contributors.

make.wordpress.org

Increased visibility through suite of P2-enabled sites.

Trac Polishing

Prettier, Better Organized and Less Intimidating to newcomers

  • Revamped UI
  • Tighter integration with other tools (make sites, SVN, IRC)
  • Easier ticket creation
  • Better ticket organization in to components and milestones

Contributor Handbooks

Project philosophies, code standards, patch writing, and more in the Contributor Handbook.

develop.svn.wordpress.org

New repository for core development

A blog post on August 6, 2013 kicked it off.

Directory structure

  • src/ — WordPress source code
  • tests/ — Test suite / test cases (PHPUnit and QUnit)
  • tools/ — Build tools (i18n)
  • build/ — Build directory

New home for the WordPress codebase.

Relegates WP to a subdirectory -- src Brings code from unit-tests.svn.wordpress.org in to the test/ directory Brings in internationalization tools in to build/

Root files

  • .gitignore
  • .jshintrc
  • .travis.yml
  • Gruntfile.js
  • package.json
  • phpunit.xml.dist

The new repository structure opens up many possiblities for root dotfiles.

Tied together by

What's a Grunt?

grunt noun

  • a short, low sound from the throat
  • a U.S. soldier especially in the Vietnam War
  • a person who does ordinary and boring work
Source: Merriam-Webster

The Javascript Taskrunner

Source: gruntjs.com

What is a Task Runner?

  • Tool that makes developers lives easier
  • Tool that makes it easier to get code ready for production

A Brief History

Tools like this don't come from nowhere. Put Grunt in context.

Before the Web

gcc -c main.c command.c display.c utils.c
gcc -o edit main.o command.o display.o utils.o

The idea of a "task runner" is not a new concept, nor is it exclusive to the web.

Compiled languages like C, Objective-C, etc. have been using them for years. In those environtments the idea of "building" code -- i.e. compiling source files into machine code and linking libraries -- is not optional. The simplest way to do this is to invoke the compiler (e.g. gcc), feeding it a list of files and configuration flags.

As you might imagine this approach does not scale, and developers quickly realized that building was for the birds.

GNU Make

Make was one of the first tools to solve this problem, and Grunt borrows a lot of concepts.

Makefile Syntax

target ... : prerequisites ...
    recipe
    ...
    ...
Source: gnu.org/software/make/

With Make developers created a "makefile", a set of instructions for how to build the project.

Developers could define "build targets" and their prerequistes and provide a "recipe" of build steps for each. Targets were not just confiend to building: - make test -- run unit tests - make clean -- clean build artificats - etc.

edit : main.o command.o display.o utils.o
         gcc -o edit main.o command.o display.o utils.o

 main.o : main.c defs.h
         gcc -c main.c
 command.o : command.c defs.h command.h
         gcc -c command.c
 display.o : display.c defs.h buffer.h
         gcc -c display.c
 utils.o : utils.c defs.h
         gcc -c utils.c
 clean :
         rm edit main.o command.o display.o utils.o
Source: gnu.org/software/make/
$ make            # Build the project
$ make test       # Run unit tests
$ make install    # Install resulting binary in your $PATH
$ make clean      # Clean up build artifacts

With a makefile in place the build process (and associated tasks) can be trigger with some simple commands.

A much easier way to build a project -- much less error prone, much easier to share among developers, and much easier to automate.

Enter The Web

In the early days of the web, build tools were unnecessary. You don't need a build tool to upload an HTML file to a web server. So do they exist?

Web Projects Got Hard!

  • Increase in scale / complexity of web projects
  • Focus on performance
  • Team environments

Grunt and tools like it were built to scratch an itch that many front-end developers started feeling a few years ago.

Increase in size and complexity of web projects Performance rennaisance brought on by the age of mobile Team environments and some of the complexities they introduce -- getting new developers started on a project, consistent development processes, etc.

We built tools to make our lives easier

  • SASS / Less
  • Coffeescript
  • jslint / jshint
  • Etc...

We got *really* cozy with our terminals. But...

$ sass --watch app/sass:public/stylesheets
$ coffee -o lib/ -cw src/
$ uglifyjs --self -c -m -o /tmp/uglifyjs.js
$ jshint --reporter=myreporter.js myfile.js

One Tool To Rule Them All...

As the number of tools exploded, the need for a unified interface for project builds became apparent.

Why use a task runner?

In one word: automation. The less work you have to do when performing repetitive tasks like minification, compilation, unit testing, linting, etc, the easier your job becomes. After you've configured it, a task runner can do most of that mundane work for you—and your team—with basically zero effort. Source: gruntjs.com

Prerequisites

1. Install Node / NPM

Grunt is a Javascript Task Runner built with Javascript, so you need a Javascript run time to use it. In this case V8 by way of Node.js.

NPM is the de facto package manager for Node.js, and is used to install Grunt itself as well as the plethora of community curated plugins.

Many of you probably have both of these installed already, but if not visit nodejs.org to get started.

$ brew install node

On the Mac I like Homebrew for node.js installation -- one command and you have both node and npm installed in an easily upgradeable package.

2. Install Grunt CLI

$ npm install -g grunt-cli

Once NPM is installed it's one command to install the Grunt CLI. This is a good one to install globally as you're likely to use it on several projects.

Grunt 101

Configuration Files

  • package.json
  • Gruntfile.js
package.json -- Consumed by the NPM command line client. Used to define development dependencies. Gruntfile.js -- Grunt configuration file. Holds task definitions for the project.

Both should be committed with your project.

Some Terms

  • Task
  • Target
Task - Something to do with the code. Lint. Test. Compress. Etc. Target - Recipient of the task. Names are arbitrary. Target could be "all", "scripts", "styles", etc.

CLI

$ grunt <task>[:<target>]

# Examples

$ grunt build           # Run the `grunt build` task on all targets
$ grunt build:scripts   # Run the build task for "scripts" target only
$ grunt                 # Run the default task (if confiugred)

Working with Grunt

There're two different workflows to discuss:

Setting up Grunt with a new project (or introducing it in to an existing one) Working on an existing project that has a Gruntfile in place

Starting a New Project?

Determine what tasks are needed Create a package.json file to capture dev. dependencies Create a Gruntfile to define the tasks Commit both to project root Run tasks and prosper

Continuing an Existing Project?

Pull down from source control Run tasks and prosper

Best way to learn is by example

Demo Time

develop.svn.wordpress.org

Summary

# Fetch project from VCS, install development dependencies
$ svn co http://develop.svn.wordpress.org/trunk
$ npm install

# Run tasks and prosper
$ grunt --help          # List tasks
$ grunt [build]         # Run default task (build)
$ grunt uglify:core     # Uglify scripts in the "core" group
$ grunt jshint:themes   # Lint scripts in the "theme" group with jshint
$ grunt test            # Run all PHPUnit and QUnit tests

Demo Time

BU Navigation

Summary

# Fetch project from VCS, install development dependencies
$ git clone git@github.com:bu-ist/bu-navigation

# Initialize package.json
$ npm init

# Install Grunt and friends, saving dependencies in package.json
$ npm install grunt --save-dev
$ npm install grunt-contrib-uglify --save-dev
$ npm install grunt-contrib-concat --save-dev
$ npm install grunt-contrib-watch --save-dev

# Edit Gruntfile...

# Run tasks and prosper
$ grunt
$ grunt uglify
$ grunt concat
$ grunt watch

See the grunt-presentation branch of my fork of the navigation plugin.

Questions?