What makes me "Grunt"?

Slides from my talk at Confoo 2014. Notes to come...

As a front end developer, I want to write code. Dealing with the mundane tasks that come with static assets such as concatenation, minification and versioning, I don't care much for. In this session, I'll explain how to setup Grunt tasks to handle CSS and JavaScript assets in both development and production environments. This automated workflow allows you to easily reproduce both environments locally for testing and debugging.

## Resources
* http://www.getchef.com/
* http://www.vagrantup.com/
* http://www.phing.info/
* https://getcomposer.org/
* http://www.gruntjs.com/
* http://www.bower.io/
* http://www.npmjs.com/
* http://github.com/canvaspop/grunt-static-versioning

## Links
* http://fabien-d.github.io/
* http://twitter.com/fabien_doiron
* http://canvaspop.com
* http://dna11.com
* http://crated.com
* http://developers.canvaspop.com
* http://remade.canvaspop.com/

Transcript

1. what makes me “Grunt”? developer happiness courtesy of automation / Fabien Doiron @fabien_doiron
2. no automation make me go something something
3. I work on Crated software developer, front-end @fabien_doiron
5. when I got into development front-end development was pretty simple
6. typical tools HTML / CSS / JS / FTP / browser
7. then something happened front-end development became complex
8. current typical tools linting / preprocessors / concatenation / minification / versioning / testing / coverage / dependency management / continuous deployment / version control / frameworks / libraries…
9. tools mentioned from our stack
10. environment: back-end: front-end:
11. 4 reasons we use build tools & automation
12. build tools in 10 seconds or less
13. what? automation
14. why? automate what you have but don't want to do
15. how? configure a task once, run as often as you want ~ ▸ build task:target
16. who? Grunt, Gulp, Phing, Make, Rake, Jake, Brunch, Ant…
18. 1. project setup
19. project setup: goal coding ready in minutes
20. project setup: tools environment: build tools:
21. project setup in 3 easy steps
22. i. ~ ▸ git clone … # get code from repository ~ ▸ git pull # get latest code from repository
23. ii. ~ ▸ vagrant up # puts together a complete environment # provision environment with chef
24. iii. ~ ▸ phing proj:build # get deps with composer, npm & bower # database migration with phinx # front-end build with grunt ~ ▸ grunt build # lint, preprocess, concat, min, version # my personal favourite: ascii
27. 2. project output
28. project output: goal reproducible results regardless of developer setup/workflow
29. reduce the risk of “works on my machine” by abstracting the output settings from the user to the build tool
30. project output: tools
31. compiling CSS: user settings ~ ▸ sass in.scss:out.css ~ ▸ lessc in.scss > out.css results: can vary
32. example task (Sass) module.exports = function ( grunt ) { var src = '<%= grunt.option( "src" ) %>'; var tmp = '<%= grunt.option( "tmp" ) %>'; grunt.config( 'sass', { dist: { files: [ { expand: true, cwd: src + '/sass', src: [ '*.scss' ], dest: tmp + '/sass', ext: '.css' } ] } } ); grunt.loadNpmTasks( 'grunt-contrib-sass' ); };
33. compiling CSS: tool settings ~ ▸ grunt sass ~ ▸ grunt less results: are the same
35. 3. coding environment
36. coding environment: goal easily work in a dev and/or production replica environment
37. coding environment: tools
38. coding environments setup in 4 easy steps
40. i. separate targets ~ ▸ grunt build:dev # all source files, commented, unminified ~ ▸ grunt build:prod # concat, minified, versioned files
44. grunt versioning task versioning: { options: { cwd: 'public', outputConfigDir: 'public/config' }, dist: { files: [{ assets: '<%= uglify.main.files %>', key: 'global', dest: 'js', type: 'js', ext: '.min.js' }, { … } ] } }
47. iii. generated configuration file ~ ▸ grunt build:dev <?php return array( 'static.assets' => array( 'global' => array( 'css' => array( '/static/css/main.css' ), 'js' => array( '/static/js/file1.js', '/static/js/file2.js', … ) ), 'home' => array( 'css' => array(), 'js' => array( 'static/js/home1.js', '/static/js/home2.js' ) ), 'anotherKey' => array( … ) ) );
48. iii. generated configuration file ~ ▸ grunt build:prod <?php return array( 'static.assets' => array( 'global' => array( 'css' => array( '/static/css/main.7f41197e.min.css' ), 'js' => array( '/static/js/plugins.7409b19a.min.js', '/static/js/common.4923a32c.min.js', … ) ), 'home' => array( 'css' => array(), 'js' => array( 'static/js/home.47b0990d.min.js' ) ), 'anotherKey' => array( … ) ) );
51. ii. generated output ~ ▸ grunt build:dev ~ ▸ grunt build:prod ▾ public ▾ static ▾ css main.css ▾ js plugin1.js plugin2.js common1.js common2.js home1.js home2.js … ▾ public ▾ static ▾ css main.7f41197e.min.css ▾ js plugins.7409b19a.min.js common.4923a32c.min.js home.47b0990d.min.js …
57. iv. use generated configuration file // inside our layouts <?php $this->versionedAsset()->render( 'global' ); ?> ~ ▸ grunt build:dev ~ ▸ grunt build:prod <link rel="stylesheet" href="/static/css/main.css"> … <script src="/static/js/file1.js"></script> <script src="/static/js/file2.js"></script> … <link rel="stylesheet" href="/static/css/main.7f41197e.min.css"> … <script src="/static/js/plugins.7409b19a.min.js"></script> <script src="/static/js/common.4923a32c.min.js"></script>
58. why did we go down this road?
59. cloudfront invalidation ~15 minutes no longer applicable* *appending a hash creates a “new” file
60. cleaner includes in our layouts messy if( APPLICATION_ENV == "production") { // include concat/min files } else { // include all dev files } clean <?php $this->versionedAsset()->render( 'global' ); ?>
61. demo
62. 4. debugging
63. debugging: goal effectively debug errors
64. debugging [ compiled, ] concatenated, minified code is hard
65. our approach when a bug is found/reported
66. i. build dev environment reproduce the error rule out minification error use devtools on source files update/add unit, integration, regression tests generally all we need
67. ii. build prod environment reproduce the error use devtools with source maps still have access to source files easier to debug than on the live site update/add unit, integration, regression tests
68. “trying to fix a bug in minified code is like using a new API with no documentation”
69. recap
70. being a front-end developer is hard build tools make you awesome automate the repetitive tasks frictionless project setup reproduce output every time access to dev and production environments locally take the stress out of debugging
71. resources chef vagrant phing composer grunt bower npm grunt static versioning
72. CONFOO2014 40% off coupon code because you were awesome *valid until March 30, 2014
73. thank you questions / Fabien Doiron @fabien_doiron