Upgrade to Pro — share decks privately, control downloads, hide ads and more …

What makes me "Grunt"?

2a622fe29c34d10f5edbcf3ea15e1bf1?s=47 Fabien Doiron
February 27, 2014

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/

2a622fe29c34d10f5edbcf3ea15e1bf1?s=128

Fabien Doiron

February 27, 2014
Tweet

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

  4. None
  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…

  17. None
  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
  25. None
  26. None
  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
  34. None
  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

  39. None
  40. i. separate targets ~ ▸ grunt build:dev # all source

    files, commented, unminified ~ ▸ grunt build:prod # concat, minified, versioned files
  41. None
  42. None
  43. None
  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' }, { … } ] } }
  45. None
  46. None
  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( … ) ) );
  49. None
  50. None
  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 …
  52. None
  53. None
  54. None
  55. None
  56. None
  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