Build systems > Gulp

[addyosmani]

Gulp is a streaming build system. Like Grunt, but faster and less config. There currently aren't a lot of tutorials about Gulp out there at the moment.

It would be useful to cover some of the same items in #2, but with a focus on using Gulp plugins, talking about how it differs from other build systems etc.

[sindresorhus]

@travm might be interested as he has written a couple of articles on Gulp.

[addyosmani]

Thanks @sindresorhus! Being relatively new there are still a lot of best practices around Gulp that have yet to be documented and I'd love to see a chapter on it in here.

[travm]

I'd be glad to help out. Just let me know how we'll be organizing the information and where to begin work.

[addyosmani]

Fantastic. Will let you know as soon as we have the basic setup for contributing committed.

[addyosmani]

Okay, now that we've got the basics for #8 (build system) in place, I think we're ready to start accepting contributions. @travm would you like to propose what topics a Gulp chapter should ideally cover? Would love to have you author if you'd be down for that.

[travm]

Using what was mentioned in issue #9 by @rowoot I think this would be a good start.

• Introduction
  • Why Gulp?
  • How Is It Different?
• Getting started
  • Installation (How Detailed Should This Be?)
  • Debugging (Common Installation/Getting Started Issues - or should this be included in the final section below?)
• gulp Specific/Simple Code Walkthroughs
  • Adding A Linter
  • CSS Preprocessing
  • Local Server/Live Reload
  • Running Tests
  • Deployment
• Best Practices
• Troubleshooting/Common Issues

How detailed would we want the installation notes to be? Since most Node tools will share a similar installation process, should we start from the very base of installing Node? Or, should we assume that the reader has already viewed the introduction chapter for Node and npm?

[addyosmani]

That looks like a great start. I would say we should assume that Node and npm are already available and setup. We'll cover how to do this in the first chapter so that there doesn't have to be repetition there. We can always refer readers back if they aren't familiar with the tools needed to setup :)

[michealbenedict]

I like @travm's idea of having code walkthroughs (assuming these are links to plunkr/jsbin/jsfiddle) as part of the tool specific content. I somewhat feel that there could be an overlap between "Best practices" content and the tool specific content. Probably we should roll up the "Best practices" section?

[travm]

@addyosmani Sounds great! Let's create the folder/file structure for the chapters and the sections and how they relate, just to be sure we wont have any conflicts as users begin writing content. Should each chapter and section have it's own separated .md file or will we be adding information to a shared .md file? Should we separate each chapter inside of its own folder? I'm not sure what would be best for everyone contributing and how this would affect the build that has been setup.

@rowoot I think you're right. Unless we can identify specific cases where we need a Best Practices section, I think we could probably roll that up until we absolutely need it. We may need to check with the authors for the other tools to ensure those tools don't need a separate Best Practices section. It may be best to leave it as an optional section as needed, where the other sections we've outlined should be consistent.

[michealbenedict]

@travm and @addyosmani What are your thoughts on the following structure https://github.com/rowoot/book-of-modern-frontend-tooling/tree/file-structure/chapters

The directory structure might something like this

• Chapters
  • {tool-name}
  • section-{*}.md

Pros:

• Easier to maintain and accept PR for specific portions of the content.
• From a dev perspective, we can be creative on how these markdowns can be exported to specific formats (Eg, grep section-* > single html or generate TOC based on section-*)

Cons:

• Some files might have less to no content, while some (like the tool specific content) will have loads of content

[addyosmani]

I like the proposed structure. What about assets like images? Should all chapters share the same image directory or should each chapter have its own? Once we have that down I'm happy with us to move forward with the above.

Thanks again!

[travm]

I'm leaning a bit toward the single image directory. Unless we decide to put each chapter into it's own folder (with the images and sections as subfolders). @rowoot, what are your thoughts?

[ajoslin]

I think one shared assets directory would be best, because we may re-use some images. We can always prefix images by section/chapter if they are collision-risky.

[michealbenedict]

@travm and @ajoslin based on your input, I have an example layout at #9 (comment). Feedback appreciated.