Dealing with your Gulp addiction

We’ve all been there. New project, a chance to finally use those gulp modules you’ve been reading about, lets do it!. 3 Weeks later you’ve got a 700 line Gulpfile and it’s always breaking. You’re spending just as long maintaining the file as doing actual work, and you’re pretty sure that half of them aren’t actually running any more.

Having been there myself this is my guide for breaking out of the cycle.

Transcript

1. DEALING WITH YOUR ADDICTION Barney Scott
2. Senior Front end developer WHO AM I? 13 Years working as a dev @bmds bmds
3. I LOVE TASK RUNNERS
4. THERE’S LOTS OF CHOICE
5. THERE’S LOTS OF CHOICE
6. THERE’S LOTS OF CHOICE
7. BUT I THINK WE HAVE A PROBLEM
8. THE PROBLEM We keep building complicated, difficult to manage, fragile task runners that change with each project. The only person that mostly understands it is the person who originally wrote it.
9. THE SOLUTION Treat your task runner like the rest of your code
10. DEVELOPERS CAN’T BE TRUSTED
11. 6 STEP PROGRAM
12. THE RULES Step 1
13. GIVE YOURSELF RULES • Re-use your task runner between projects • One new module per project • Only add modules at the start of the project • Ask yourself if the project really needs this module.
14. THE PROBLEM We keep building complicated, difficult to manage, fragile task runners that change with each project. The only person that mostly understands it is the person who originally wrote it.
15. GIVE OTHERS RULES • Discuss what you’re doing • Write down the result • Version the notes
16. THE PROBLEM We keep building complicated, difficult to manage, fragile task runners that change with each project. The only person that mostly understands it is the person who originally wrote it.
17. UNIFY SETTINGS Step 2
22. THE PROBLEM We keep building complicated, difficult to manage, fragile task runners that change with each project. The only person that mostly understands it is the person who originally wrote it.
23. SPLIT UP YOUR TASKS Step 3
24. SPLITTING UP TASKS • Group by logical action • Bake in quality (linters etc) • Makes it easier to Re-Use single parts • Reduces cognitive load Step 1
25. THE PROBLEM We keep building complicated, difficult to manage, fragile task runners that change with each project. The only person that mostly understands it is the person who originally wrote it.
26. TREAT IT LIKE A UI Step 4
28. THE PROBLEM We keep building complicated, difficult to manage, fragile task runners that change with each project. The only person that mostly understands it is the person who originally wrote it.
29. NO CLEAN SLATE Step 5
30. THE PROBLEM We keep building complicated, difficult to manage, fragile task runners that change with each project. The only person that mostly understands it is the person who originally wrote it.
31. SHRINKWRAP IT Step 6
32. HOW YOU SHRINKWRAP $ npm shrinkwrap npm-shrinkwrap.json https://docs.npmjs.com/cli/shrinkwrap
33. THE PROBLEM We keep building complicated, difficult to manage, fragile task runners that change with each project. The only person that mostly understands it is the person who originally wrote it.
34. BONUS ROUND Step 7
35. https://greenkeeper.io
37. https://snyk.io
38. COMMITIZEN https://commitizen.github.io/cz-cli
39. http://lean.codecomputerlove.com/commit-messages-and-git-hooks/
40. ANYTHING ELSE? • Lint it - ESLint / JS Hint / JS Lint • run-sequence - Gulp 4 • Lazy load plugins
41. USE SOMEONE ELSE'S CODE Step 1A
42. WHERE ARE WE NOW • Simplified your tasks • Made them more robust • Talking about what you’re doing • Moving at a sensible rate of change • Treating it like code
43. YOU’RE PRETTY INCREDIBLE
44. YOU’VE STILL GOT PROBLEMS
45. CARTRIDGE Step இ!?
46. WHAT IS IT? • Very stripped down base project • Series of curated tasks split in to NPM modules • Command line tool to help
48. WHY? • Speed of getting started • Easy upgrade path • Design in the browser • Focus on quality http://github.com/cartridge
49. IT’S PERSONAL
50. THANKS Any questions?