Upgrade cosmiconfig to 3.x

[okonet]

https://github.com/davidtheclark/cosmiconfig 2.x offers caching and transform function that should potentially make #262 obsolete.

[okonet]

https://github.com/okonet/lint-staged/blob/master/package.json#L74 can be removed as well if we do that.

[sudo-suhas]

3.0 is going to be released soon. We should update to that.

[okonet]

Agreed! Let's wait.

[okonet]

@sudo-suhas I didn't realize you're #2 contributor of cosmiconfig! 🥇

[okonet]

For that reason I've assigned you ;) Hope you don't mind.

[sudo-suhas]

Ha ha.. It would be a pleasure 😁

[luftywiranda13]

yesss, we have @sudo-suhas here 🎉

[sudo-suhas]

@okonet cosmiconfig 3.0 has been released. I want to understand a couple of things before upgrading.

Why do you think we should use caching and transform?
From the cosmiconfig readme

The reason you might use this option instead of simply applying your transform function some other way is that the transformed result will be cached.

I think the cache and transform would have been relevant if we were invoking explorer.load multiple times.

cosmiconfig now also supports loading the config synchronously. Would you like me to use that?

[okonet]

I was under impression that using cache and transform will cache the transformed full config once (on the file system) and won't do that for any consequent calls. Since lint-staged config is rarely changed, I think it could improve the overall time of execution but I might be wrong. Also, transform will save us some work on getConfig optimization I hoped.

[okonet]

I don't think we should use sync mode besides there are clear benefits of doing this. I'd like to stick the code style to be promise based for most parts.

[sudo-suhas]

The cache is in-memory, not useful for our usage right now. But the file-system cache is a good idea. I might try to implement that in cosmiconfig.

[okonet]

Good to know. Not sure how much benefit it will gain without inspecting the bottlenecks first.

[okonet]

Wondering what was the use-case for caching in the first place.

[sudo-suhas]

If you have something like stylelint, it has to call explorer.load repeatedly for different files or directories. So caching what you know about the config files you found should help. I only started working on cosmiconfig recently so I am just guessing. @davidtheclark will know better.

[davidtheclark]

If you have something like stylelint, it has to call explorer.load repeatedly for different files or directories.

Yep. The reason I introduced caching was because stylelint wanted to switch from looking up a single configuration, once, to looking up a configuration for every particular file — allowing for different directories to use different configurations, but all linted in the same process. stylelint calls explorer.load, then, for every single file it analyzes. That's when in-memory caching should pay off.

[okonet]

Okay so it seems to be a not so good fit for us...

[jksmithing]

Want to note, too, that cosmicconfig@3 removes support for --config, which is useful when running lint-staged from a directory that is not process.cwd() (i.e. when used as part of another package). Maybe we could add support for --config to lint-staged if we do upgrade to cosmicconfig@3.

[cameronhunter]

@neonsilk PR #304 adds support for --config