That's cool.

from blendid.

I took it a step further in my fork. I added a userconfig-example.json and added userconfig.json to gitgnore. So it's possible to rename userconfig-example to userconfig.json and override some user specific parameters, for example browserSync proxy. In my config.json are project specific settings, in the userconfig.json user specific settings for their local environment.

Just as an input.
https://github.com/whatwedo/gulp-wp-theme/tree/develop/gulp

from blendid.

👍 to this.

Combining this with @renestalder's user-config would be nice. So, simply merge the default config with user-specific config, which is added to .gitignore.

from blendid.

I definitely 👍 the idea of a .gitignored userconfig + default example included in the repo. Extending might be nice but then you'd have defaults in one file and user config'd stuff in another file... I might personally prefer just one config file i.e. default exists, copy it and rename to userconfig and then edit.

from blendid.

@solomonhawk @tommymarshall Yeah, I recognised my solution isn't perfect because I take the default parameters out of the example config (similar to WordPress where the example config is needed for the installation), instead out of the config.json where I could define defaults.

But I wanted a strict separation between user specific parameters and project parameters. For example, folder structure for builds should be project wide while browserSync settings for browser and proxies could be user specific. All defaults in the config.json is okay, but IMHO not all should be changeable by the user settings.

from blendid.

I like this, and agree it's a good idea. I've been meaning to do this for a while. For the sake of simplicity, (this is just a starter repo) I'll just add a single config file.

from blendid.

Loving this idea, @solomonhawk!

Do you guys see a benefit in making this a module instead of JSON?

• Both JSON files and modules can be required
• a module can be coffee, js or JSON
• a module lets you re-use variables and do useful things such as

# gulp/config.coffee

dest = './build/'
src  = 'src'

module.exports =
  sass:
    src : "#{src}/sass/*.{sass, scss}"
    dest: dest

  images:
    src : "./#{src}/images/**",
    dest: "#{dest}/images" 

These seem like very valuable benefits at virtually no cost, right?

from blendid.

I agree entirely, module seems like the way to go

On Sep 7, 2014, at 10:30 AM, Andreas Pizsa [email protected] wrote:

Loving this idea, @solomonhawk!

Do you guys see a benefit in making this a module instead of JSON?

Both JSON files and modules can be required
a module can be coffee, js or JSON
a module lets you re-use variables and do useful things such as

gulp/config.coffee

dest = './build/'
src = 'src'

module.exports =
sass:
src : "#{src}/sass/*.{sass, scss}"
dest: dest

images:
src : "./#{src}/images/**",
dest: "#{dest}/images"
These seem like very valuable benefits at virtually no cost, right?

—
Reply to this email directly or view it on GitHub.

from blendid.

I've been using my config as a module for a while, one of the benefits i like is able set options and default values for variables.
I use it with yargs so you can specify your dist when running your gulp task in term

args = require("yargs").argv
buildDir = args.dir ? "dist"
module.exports =
  build:
      root    : "#{buildDir}"
      folders:
        fonts   : "#{buildDir}/fonts"
        image   : "#{buildDir}/images"
...

from blendid.

@adrianchen19888 Oh nice! Yargs looks great.

from blendid.

I'll use that when I add dist/production tasks.

from blendid.

Done. Thanks @AndreasPizsa and everyone who contributed to the conversation!

from blendid.

Just reading up on all this. Nice work! 👍 to reducing repetition of of paths and the module implementation!

from blendid.