Make cssnano configurable

[shawwn]

Closes #347.

[brandon93s]

For other cases where the preset was not explicitly set, cssnano will look for a section in your package.json or a cssnano.config.js, from the current working directory upwards until it reaches your home directory.

Hmm, docs imply this would be loaded automatically.

[shawwn]

Yeah, I noticed that. But it's probably better for the configuration to go through Parcel's config system rather than rely on automatic behavior.

Want to test whether cssnano is currently configurable without this PR?

[devongovett]

Did anyone end up testing whether cssnano already loads this config file?

[shawwn]

Even if it does by default, it would be better to apply Parcel's config loading logic.

In general, Parcel should be responsible for providing all configuration. This will be necessary in order to detect which assets should be rebuilt when a config file is changed.

(Conceptually, every asset that loads a config file should add that config file as a dependency, so that when the config file changes, that asset is rebuilt.)

That's the ideal design, anyway. Parcel doesn't work that way yet, but I'm hoping to make those changes eventually.

[shawwn]

So to clarify, it would be good to merge this PR as a step toward that goal, if you agree.

[devongovett]

Good point. Should we also support .cssnanorc and .cssnanorc.js names like other things in parcel do?

[shawwn]

I considered that, but decided it would be better to stick with exactly the names that are already supported. E.g. if FooLanguage expects foo.config.js, then we should only look for foo.config.js and nothing else. This will lead to minimal confusion, because we can simply say "Go read their docs! We do whatever they do." Conversely, if we don't do what they do, then that would be considered a bug on our end. The principle here is "Users should be able to guess Parcel's behavior without having to read the docs." In absence of information, it would be reasonable for users to expect that Parcel supports cssnano.config.js but not .cssnanorc{,.js}.

…

On Sat, Dec 30, 2017 at 2:41 PM, Devon Govett ***@***.***> wrote: Good point. Should we also support .cssnanorc and .cssnanorc.js names like other things in parcel do? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#414 (comment)>, or mute the thread </~https://github.com/notifications/unsubscribe-auth/AADo8Jp53J_XhzkgboE2sPN7u4I_-Bqaks5tFp_6gaJpZM4RNf8E> .

[brandon93s]

The argument for detecting asset rebuild on config change is absolutely valid.

We do however need to be careful of the situation where we use localRequire and are internally resolving configurations. In this scenario, we won't have control over what version is being required and by extension what config values, format, etc are supported. In these scenarios, config resolution is best left to the module itself if supported out of the box.