Add Gulp tasks

[MrSlide]

For the usual stuff.

• Compile JS and minify
• Compile CSS
• Optimize images
• Run tests
• Run test coverage reports
• Watch for changes
• Lint code
• Start server instance

Gulp should make use of the .env file do run tasks accordingly.

For watching for changes, I suggest using the gulp-watch module instead of the native watch function of Gulp, as the native function will only watch for changes on existing files and ignore any files created after running the watch task.

[samhh]

What benefits does this provide over Webpack, especially pertaining to code assets?

[MrSlide]

Gulp is not a replacement for Webpack and Webpack is not a replacement for Gulp, they are very different tools with very different goals.

Gulp is a task runner, and Webpack is a module bundler.

Webpack should not be dealing with CSS, images, and other types of assets, it should only be dealing with JS and templates, there should be a separation of concerns, and Gulp would be the glue for all the different compilation and bundling tasks.

[samhh]

Makes sense, but to counter:

Webpack's HMR with our own backend server requires the conditionally loaded Webpack code within the server. Webpack does not load the server but rather the other way around.

Webpack should not be dealing with CSS, images, and other types of assets, it should only be dealing with JS and templates

I think that's debatable. Near enough the entire Webpack community that I can see uses it for more than just JavaScript. It's undoubtedly less of a task runner than Gulp but it's capable of everything I've thrown at it so far. Also, from the Webpack readme: it is also capable of transforming, bundling, or packaging just about any resource or asset.

As I said in another issue, one benefit of putting CSS through Webpack is that we're then using one injection server instead of two (HMR vs HMR + BrowserSync).

You're adding another tool to the chain that will arguably complicate and slow things down.

[MrSlide]

Just because you can, doesn't mean you should. I still think there should be a clear separation of concerns, and we should let the CSS files deal with styles, and the JS files deal with scripts. Also, by letting the scripts load the CSS you run into other problems, like an unstyled page if JS is disabled, or longer times to render anything on the page. There is a good reason why it's advisable to include styles in the header and scripts at the bottom of the body.

[samhh]

As I said in the other issue, our JS does not actually load the CSS in production; it merely acts as an entrypoint for Webpack to know what to bundle. In production the CSS is stripped out and included in a separate .CSS file as you can see here: https://github.com/imperodesign/generator-impero/blob/master/generators/app/templates/app/views/components/head.pug#L17 and here: https://github.com/imperodesign/generator-impero/blob/master/generators/app/templates/webpack.production.config.js#L28

It's loaded via JS in dev mode for a much simpler build/watch solution in Webpack.

[samhh]

Closed for inactivity.