Remove Gulp as a dependency

[chrisdmacrae]

I'm proposing we remove Gulp as a dependency, based on the following thought process:

Gulp should only be used for running highly specific tasks (e.g, I wanna find files that match this pattern and create new files or apply very creative transformations on them that entail multiple steps). Gulp is overkill for general asset pipelines.

In this scenario, the raw processors can likely do the job just as well (if not better), plus using them directly will:

• Eliminate abstractions (like gulp-postcss)
• Allow us to more quickly update dependencies (like webpack@4.0)
• Not use gulp's crappy watch functionality

---

I'll create a branch called remove-gulp, wherein I will remove gulp, leaving:

• webpack@4.0 & webpack-cli: this means faster, leaner, smaller builds
• postcss & postcss-cli: this means faster CSS builds, and the ability to completely abstract away PostCSS configuration
• imagemin & imagemin-cli: we don't need no gulp.
• svgo: we don't need no gulp.

---

Is there any defaults to webpack, postcss, or imagemin that they'd like to share. Calling all static site power rangers. @budparr @ncphillips @scottgallant @jamespohalloran

[budparr]

Here's an example of one of my webpack config files. It's a bit of a work-in-progress, but it's set up to process PostCSS/Tailwind, PurgeCSS, fonts, Mustache (for Algolia), and, uh, JS: https://gist.github.com/budparr/45ffed264686f096b44e1a1ad98b30c7

Any comments on it are welcome.

[budparr]

And I applaud the removal of Gulp.

[ncphillips]

Thanks @chrisdmacrae really looking forward to seeing how this turns out. @zivbk1 may be interested in contributing as well. I will be busy over the next few days, but I will keep an eye on the discussion and code pushes.

[budparr]

@chrisdmacrae Are you intending to use postcss-cli instead of config by just calling the options in an NPM Script?

[chrisdmacrae]

@budparr Sort of. I've been doing this in some internal projects w/ some government projects, and I prefer it to using Webpack for PostCSS because you don't have to require the CSS in your JS, and you can have multiple entry points for the CSS.

You can use postcss-cli with a postcss config to get the best of both worlds.

postcss-cli PATH/TO/INPUT/DIR/*.css --config=PATH/TO/CONFIG --dir=PATH/TO/OUTPUT/DIR --ext=min.css

With this config, you can even allow for multiple input formats quite easily, as well as make it recurse:

postcss-cli PATH/TO/INPUT/DIR/**/*.{css|scss|sass}

---

Down the road I'd definitely consider using Webpack for everything once they have support for CSS as a first-party entry point (coming in 4.x.x ????).

[zivbk1]

Bud is farther down the road than I am on this issue. I'm keeping a eye on this thread.

[budparr]

@chrisdmacrae Okay, I thought you were doing without the config. Not so sure I agree with you otherwise, Webpack gives you dev/prod environments and hashing, and the extractor for PurgeCSS/Tailwinds. But generally, I want things concentrated in one place anyway, so I may be biased toward my drive for simplicity.

[chrisdmacrae]

@budparr My thought is to expose the PostCSS config both ways, in Webpack and as its own pipeline, so that you can use either workflow.

My reasoning is that a lot of static site devs aren't JS gurus, and are more used to gulp/sass approach. Being forced to require your CSS, and having no control over the output files can be very frustrating.

When Webpack@4.x releases the first party support for CSS as a valid entry point, I'll probably remove PostCSS CLI.