Implement a config file

[ben-eb]

Not until v4, because the rewrite will mean that everyone's config files will break; so I'd like to avoid making people rewrite these things too much. But I'd like to provide the option to do this; either with a .cssnano.yml or a .cssnanorc. I find YAML configs to be much nicer than JSON, but don't see why we couldn't support either one through https://github.com/davidtheclark/cosmiconfig.

This makes dependents such as atom-cssnano much simpler going forward.

[TrySound]

+1

[davidtheclark]

@ben-eb: If you find that cosmiconfig is missing something that you need, just let us know!

[ben-eb]

Will do. 😄

[sindresorhus]

package.json is all you need. Don't need more dumb metafiles. See https://github.com/sindresorhus/xo#config and https://github.com/sindresorhus/ava#configuration. No point in every tool creating their own config files when we can just keep all config in package.json. Less is more. I made pkg-conf to make this easy.

[ben-eb]

@sindresorhus You're right, hadn't considered the package.json approach. I'm not a fan of having a dozen dotfiles for configuration per-project either. 😄

[davidtheclark]

It depends on the config. Is the config for cssnano pretty small? If so, just using package.json would be fine. But, for example, I would not want to have the gigantic configs for stylelint and eslint together in my package.json obscuring the other info there: would much rather have those in separate files.

[TrySound]

I don't like package.json cause it becomes very massive with many config. And I can't use npm i without breaking "param": [ 0 ] to

"param": [
  0
]

Better use similar config language.

[ben-eb]

@davidtheclark It really depends on how many sub-modules we will have in v4's core. Some functionality that exists today as separate modules might be consolidated, other modules might be split up into separate parts.

Right now you can disable all of these modules individually, so if that is any indication of size we might be looking at a big config file. However, this is where I'd like to use presets for configuration to suit most use cases.

Like most things it seems like there is no one size fits all solution. With cosmiconfig we can use either package.json or a config file; I would be happy with supporting both if people would like us to do that, same goes for global config (which I don't personally like, projects often have different configuration on purpose, but can see its value).

[sindresorhus]

If you need to have massive amounts of config for a tool per project, the tool should probably support some kind of shareable config so you don't have to duplicate the config in each project.

[sindresorhus]

And I can't use npm i without breaking "param": [ 0 ] to

That's a small price to pay for ease of use and shouldn't be an issue for most. Just learn to live with it. You already have to with npm.

[davidosomething]

the original proposal for cosmicconfig already allows for package.json AND a config.js commonJS module, which addresses both package and shareables, doesn't it ?

[sindresorhus]

Disclaimer. I have nothing invested in this as I don't personally use this project. I just want to improve upon the current metafile mess for everyone.

Like most things it seems like there is no one size fits all solution.

That shouldn't be the goal either. You should make something awesome for the 90%.

With cosmiconfig we can use either package.json or a config file; I would be happy with supporting both if people would like us to do that

Sometimes being opinionated is a good thing. I prevents people from making dumb choices they might not even realize are dumb. I have yet to hear a good argument for why multiple config types should be supported.

[davidtheclark]

I have yet to hear a good argument for why multiple config types should be supported.

I believe the argument is that different people (like yourself) have strong opinions about how they want to configure their project, and many of those strong opinions are incompatible.

[sindresorhus]

I'm not looking for opinions about preferences. We all have our own. I'm looking for actual reasons why having it only in package.json wouldn't work for people.

[davidtheclark]

Different people have their different opinions because of different reasons. If you don't like their reasons, that's why you have a different opinion. You've heard a couple of reasons above that haven't convinced you to change your opinion, but I'm not sure you've convinced others to change theirs. So it goes.

[davidosomething]

For the cssnano project in particular, package.json is sufficient -- CSS optimizations shouldn't have rendering side effects so can be made global.

But -- completely off the cssnano topic but related to package.json's inadequacy

For other projects I think an issue is that package.json is global. How do you provide a different set of configs for a sub directory via package.json, start adding 'path/': { settings }, 'path2': {settings}?

Separate RC files might be needed if you are following multiple coding standards in your own project -- e.g.:
given: scss-lint BEM selector rule (or node sass-lint)
given: your website SCSS in BEM
given: a carousel plugin in non-BEM SCSS
given: you have overrides for the carousel SCSS split in carousel/*/.scss

Running sass-lint over your project would result in BEM violations in carousel/**/*.scss. If it were just a file, you could add an inline settings override. That gets unwieldy with multiple files, so you really need a separate config in carousel/.scsslint.yml

Now think about a large enterprise project where there are multiple such plugins, each with its own coding style that you want to keep in line with.
Will you keep adding paths to package.json? Eventually getting a 2mb package.json file because of so many overrides per-path?
What if you remove some plugins? You have to go through package.json and remove those path-based overrides too. Package.json becomes unmaintainable.

[sindresorhus]

@davidtheclark My mistake for not being clear. I'm looking for technical reasons why having config only in package.json wouldn't work. Aesthetics and preferences aside.

[sindresorhus]

@davidosomething In XO we solved it this way: https://github.com/sindresorhus/xo#config-overrides

That gets unwieldy with multiple files, so you really need a separate config in carousel/.scsslint.yml

No, carousel should be its own project with its own package.json.

Now think about a large enterprise project where there are multiple such plugins, each with its own coding style that you want to keep in line with.

Seeing how they're really different things and even with different coding style they should be separate projects.

[davidosomething]

We're digressing a bit (should we open this discussion up somewhere else?)

The carousel i was referring to was mysite/my-scss/my-carousel-overrides/, rather than the separate node_modules/external-carousel-plugin/ which would have a package.json.

the XO method you have there will end up looking like this for a large project

{ 'overrides': [
  { 
     'files': 'my-plugin1-css-overrides-for-plugin1-using-BEM/**/*.scss',
    'override1': true,
... 100 more lines
    'override101': true,
  },
  { 
     'files': 'my-plugin2-css-overrides-for-plugin2-using-OOCSS/**/*.scss',
    'override1': true,
... 100 more lines
    'override101': true,
  }
] }

[ben-eb]

A good reason for having a dotfile in the home directory would be for command line usage, say that you don't want to configure cssnano on a per-project basis, but are happy with using the CLI, and your configuration is different than the default. Like I wrote, this is something that I don't personally like (would rather configure on a per-project basis) but can see its utility.

[ben-eb]

I've settled on both package.json & cssnano.config.js. package.json is for simple/no-customisation use cases, and cssnano.config.js is for when you might need to pass functions as options. For example, https://github.com/ben-eb/postcss-reduce-idents#encoder is one such option.

These two configurations are identical; package.json:

{
  "name": "awesome-application",
  "dependencies": {
    "cssnano": "^4.0.0"
  },
  "cssnano": {
    "preset": [
      "default",
      {"discardComments": {"removeAll": true}}
    ]
  }
}

Or, using cssnano.config.js:

const defaultPreset = require('cssnano-preset-default');

module.exports = defaultPreset({
  discardComments: {
    removeAll: true,
  },
});