Allow multiple .css to be compiled

[GaryJones]

Like we support different combinations of JavaScript files being configured to be concatenated and minified, we should allow the same for CSS files.

Right now, the build:css task is hard-coded around style.scss to style.css. This means it's not reusable to build files like editor-style.css, or edd.css. Having a css configuration block might also be the start of a workaround for #3.

Initially, it may be that all individual .scss go through the same build process, but ideally, we may want to configure the list of middleware items (i.e. only certain files pass through the RTL procedure).

[craigsimps]

@GaryJones I have committed some code on branch cs/41-multiple-css which is ready for testing. The principle is the same as for JS files, where we can define multiple output files and specific the SCSS file, destination and output style for each.

Config at the moment is as follows:

    scss: {
        'style': {
            src: 'develop/scss/style.scss',
            dest: './',
            outputStyle: 'compressed',
        }
    },

To extend with custom files we would do so in our theme Gulpfile.js, like this:

toolkit.extendConfig({
    theme: {
        ... shortened for brevity ...
    },
    scss: {
        'edd': {
            src: 'develop/scss/edd.scss',
            dest: './css',
            outputStyle: 'expanded',
        }
    }
});

Which will result in out SCSS file edd.scss being compiled and output to css/edd.css along with associated source map. We can also overwrite the existing rule for style.css within our Gulpfile.js if desired (it is set to compressed output style by default, but can be overwritten to expanded for example).

[GaryJones]

Looks great! cc @cdils

[GaryJones]

I've not tried to override it at the theme level yet, but the cs/41-multiple-css branch seems to keep the style.css being generated correctly 👍

[craigsimps]

Have you had the opportunity to test this @GaryJones and does it work the way you wanted?

Are we good to merge in for a new release 1.3.0?

[GaryJones]

Not tested yet, but I will do it now.

[GaryJones]

@craigsimps Your post above shows that scss should be a key directly in toolkit.extendConfig, but the example has scss under the css key under toolkit.extendConfig. This latter is what I suggested, but doesn't seem to be working like that (and actually, moving scss out of css doesn't seem to be working either). Have you got some local code that didn't get committed?

[craigsimps]

No, I've nothing which hasn't been committed. I've just created a new theme based on craigsimps/genesis-starter-theme and the gulpfile is as follows:

'use strict';

var gulp = require('gulp'),
    pkg = require('./package.json'),
    toolkit = require('gulp-wp-toolkit');

require('gulp-stats')(gulp);

toolkit.extendConfig({
    theme: {
        name: pkg.theme.name,
        homepage: pkg.homepage,
        description: pkg.theme.description,
        author: pkg.author,
        version: pkg.version,
        license: pkg.license,
        textdomain: pkg.name,
        template: "genesis"
    },
    css: {
        scss: {
            'edd': {
                src: 'develop/scss/edd.scss',
                dest: './css',
                outputStyle: 'expanded'
            }
        }
    }
});

toolkit.extendTasks(gulp, { /* gulp task overrides */ });

This results in style.css in the root, and edd.css in a css/ directory. My package.json references the specific branch using

    "gulp-wp-toolkit": "craigsimps/gulp-wp-toolkit#cs/41-multiple-css"

[GaryJones]

My mistake, it seems to be working. I'd copied the example (which has develop/scss/editor.scss, but had created a develop/scss/editor-style.css, and since the names didn't match, it didn't work.

Any chance of adding in some feedback when the src file isn't found?

[craigsimps]

Have added a console.log with an error message and note of the filename:

[GaryJones]

I'd already rebased your branch, so let's go ahead with a PR and merge :-)

[GaryJones]

Just found one potential issue:

css: {
	outputStyle: 'expanded',
	scss: {
		'editor-style': {
			src: 'develop/scss/editor-style.scss',
			dest: './',
			outputStyle: 'compressed'
		}
	}
},

My aim was to have style.css generated as expanded, but let editor-style.css be generated as compressed.

With that extra outputStyle outside of the scss block, style.css reads this (or at least doesn't compress) fine. However, now my editor-style.css is also expanded - the inner outputStyle is not taking preference for the editor-style key.

[craigsimps]

Yes, it's a problem leaving the outputStyle there and referencing it. Everything should be decided by the inner key value.

[craigsimps]

I think perhaps something has gone awry in previous merges / commits as it should be baseFontSize: 16 which is the variable there, rather than outputStyle.

[GaryJones]

The baseFontSize is inherited from the config.js, so doesn't appear to need to be re-specified in the consuming theme.

Let's say that the outer outputStyle is plain wrong and won't be supported - not a problem.

But:

css: {
	scss: {
		'style': {
			outputStyle: 'expanded'
		},
		'editor-style': {
			src: 'develop/scss/editor-style.scss',
			dest: './',
			outputStyle: 'compressed'
		}
	}
}

...doesn't seem to work either - style.css is still compressed, which is the default value in config.js.

[craigsimps]

I've set up a demo theme with the following css config:

    css: {
        scss: {
            'style': {
                outputStyle: 'expanded'
            },
            'edd': {
                src: 'develop/scss/edd.scss',
                dest: './',
                outputStyle: 'compressed'
            }
        }
    }

And this has given exactly the results it should, where style.css is expanded, and edd.css is compressed.

[GaryJones]

Confirmed working, thanks!