Should we deprecate Gulp and focus on Webpack? about theme-scaffold HOT 17 CLOSED

I said I had no opinion, but that has turned out to be mostly false.

A Webpack-only setup would have to be at least as fast compiling and passing changes over to BrowserSync for a live page reload. For most projects now, Gulp is already on the cusp of not being fast enough (for me).

Simplifying / reducing is great, but Gulp is simple, portable, known (and knowable) and fast. If a Webpack project were significantly slower at compiling and live-reloading, I'd add Gulp back in just for that.

BrowserSync, too, is just another tool that some of us use, and shouldn't necessarily be the deciding factor, but overall performance equivalence with Gulp definitely should I think.

from theme-scaffold.

@timwright12 Sounds good. I'll spin it up.

from theme-scaffold.

There is now PR in #111.

from theme-scaffold.

I have two concerns:

• What is the impact for LOE in spinning up a custom build off of the scaffolding with webpack vs gulp? A lot of us are used to gulp, but I'm sure we can evolve our webpack chops as needed.
• Are there tasks many of us use in gulp that may be difficult to replicate in webpack?

Other than that, I agree it makes more sense to evolve into one task runner.

from theme-scaffold.

Also it may make sense to move some things to regular npm scripts as well. I'm for this move. The https://github.com/10up/component-scaffold uses just webpack.

from theme-scaffold.

Registering a mostly non-opinion. The only out of the ordinary thing I use is svgstore, and looks like there's a port of that (though I've not used it): https://www.npmjs.com/package/webpack-svgstore-plugin

from theme-scaffold.

@saltcod that was my original hold up, but I've since figured out a clean integration for icons: https://github.com/timwright12/webpack-starter/blob/master/assets/src/index.js#L10

from theme-scaffold.

from theme-scaffold.

@saltcod yeah, it watches the directory and creates a sprite

from theme-scaffold.

I'm having trouble finding a source for this, but It was my understanding that Gulp is faster than Webpack at compiling/minifying CSS/JS because it's a task runner, vs Webpack - a bundler. If that speed is noticeable, I think it's a strong argument for continued use of Gulp.

Additionally,
Gulp is relatively easy to configure, and this can be a win when we want to retrofit older projects with the existing theme scaffolding. Because this configuration is pretty simple, it makes continued 'support' for two tools, a bit easier to manage.

from theme-scaffold.

I'm for moving to a singular system, if it makes more sense to do so.

I think one of the bigger concerns as of now seems to be people's lack of knowledge around Webpack config files. If that's the case, it might be a good topic for us to work on together or have some presentations on so people can feel more comfortable.

I've moved a project completely to Webpack (not scaffold, originally Grunt based) and it's been fairly good so far. To @monopine's point, there is a difference in build time from Grunt, but I've been able to determine that it is largely based on the loaders involved. In particular, the project uses SCSS, which doesn't have the best loader for performance. The amount of entry points seems to also play a part. Otherwise, performance difference has been negligible between the two. I would still be interested in a performance comparison between Webpack and Gulp + Webpack.

Using Speed Measure Plugin might be a good way to do some testing (and may be good for integration anyways).

from theme-scaffold.

I'm all for this move, I've enjoyed working with webpack on a number of projects with different configuration options. Also, I like the idea of only having to manage packages for one eco system.

from theme-scaffold.

I am generally in favor of reducing the number of build tools whenever possible, so I vote yes to move to a combination of webpack (+ NPM scripts if needed). If the argument for keeping Gulp is basically "more people here know Gulp" then I don't think that's compelling enough to warrant keeping it around if webpack can do everything Gulp can and is just as performant in most cases. In my totally non-scientific, anecdotal experience, I haven't noticed much if any speed difference when using Gulp + webpack vs. webpack-only.

I think SCSS is a non-issue for the scaffold since we've moved to standard CSS + PostCSS anyway. Also, removing Gulp from the scaffold doesn't mean that no projects can use Gulp anymore, just that it's not there by default anymore—if you're on a project that needs SCSS or something that is otherwise better handled by Gulp, then by all means add it back to the toolbox for that project.

from theme-scaffold.

The original reasoning behind utilizing Gulp was mostly around the fact that Webpack is a bundler, and in order to get it to transpile our PostCSS to backwards compatible CSS was a pain, and required the implementation of Webpack specific plugins to properly execute what we needed. SVGs were also hard, and not worth the headache to implement in Webpack (@timwright12's comment above solves that issue however).

@timwright12 will this reduce the number of packages we are leaning on the scaffold? If so then I'm all for it, but if we're still utilizing a similar number of packages then I may be a little hesitant for the reason above. Webpack does it's job well when it comes to bundling JS files. Gulp does it's job well when it comes to transpiling CSS.

If the overwhelming consensus however is for moving to a single system then I'll happily back that opinion off a bit. But that was the original logic behind the initial decision.

from theme-scaffold.

Yeah, I should caveat my strongly-worded opinion that if we have to jump through hoops to move to a single system, then that defeats the purpose of "simplifying" the toolchain. If we end up needing more tools and dependencies to use webpack only, then I don't see the harm in keeping Gulp around a bit longer until webpack catches up on the CSS front.

from theme-scaffold.

About a year ago I was against using Webpack with CSS and other non-JS assets. But I have changed my mind after that, and I'd vote for using only Webpack. Version 4 with plugins can do everything under the sun.

However there are lot's of different approaches to take and several Webpack plugins will be needed anyways. I have used similar approach outlined in article An Annotated webpack 4 Config for Frontend Web Development.

It's a lot of reading and there are lot's of reasons why Webpack is used. In short the idea is this:

Split config files for

• webpack.settings.js
• webpack.common.js
• webpack.dev.js
• webpack.prod.js

webpack.settings.js would be the only file which would change from project to project even if the projects would be totally different. This will help maintaining and updating build process.

The same idea could be done using two files but I have found it handy to put dev and prod processes in their own files.

Webpack plugins to consider

These are the most common plugins that I have used and needed:

• BrowserSync plugin for Webpack: set BrowserSync.
• Clean plugin for webpack: remove build folder (dist) so that there wouldn't be any unnecessary files.
• copy-webpack-plugin: Copy static assets to build folder. I use this for images and fonts, even SVGs if I don't use "sprite method" mentioned in previous comments.
• Imagemin plugin for Webpack: compress all images in your project during build process, also SVGs using svgo.
• UglifyJS Webpack Plugin: however it seems that many have moved to Terser.
• webpack-fix-style-only-entries: removes style entry generated extra JS file.
• mini-css-extract-plugin: extracts CSS into separate files.

Loaders to consider

These are the most common loaders that I have used and needed:

• babel-loader
• css-loader
• postcss-loader

I can spin up PR for ideas outlined above if needed.

from theme-scaffold.

@samikeijonen that'd be great if you could create a PR for it that uses all the current tool. My only request is that we move the webpack files into a /config directory so they're not clogging up the root and it all runs off the current build commands.

from theme-scaffold.