Install a .clang-format file instead of delegate to gts package .clang-format

[usergenic]

This is useful for IDEs and tooling to recognize the intended clang-format settings for format-on-save behaviors etc.

[ofrobots]

Thanks for the suggestion! I think it is a good idea. The only reason we didn't do it so far to make sure we roll out updates to the config without having to force users to update their local copies. The use case of exposing the setting to the IDEs is a good one though.

We can probably install a copy at init time, and do an up-to-date check on gts check and gts fix.

[JustinBeckwith]

As much as I'd like the IDE integration, part of the appeal of this library is that it's a no-config, easy to update, opinionated thingy. Once we start exposing the .clang-format, its a slippery slope to not being opinionated.

I wonder how tools like standardjs and prettier handle this kind of stuff.

[usergenic]

If the IDE doesn't support redefining the config file location, a temporary workaround as a developer can be to copy or symlink to the files inside ./node_modules/gts/.

I personally like the idea that gts check could basically warn "hey you have a local config which is different than the one in the gts package" and "gts fix" could remedy by refreshing local/overwriting it. Whether gts init always installs the local copies may not be as important, though it would be nice if it had a flag/option to do so.

[usergenic]

This matters for tslint.json too although in the tslint.json example they can have an extends property that references the gts package's config. (#119)

[ofrobots]

I think the slope would be a lot slipperier for tslint.json. For .clang-format, there is so little to customize in there (it's a 1-liner). Providing a copy of the file doesn't necessarily invite the user to go edit it, IMO. If a user really does go and edit their format, they really, absolutely, wanted to follow a different coding format.

If such a user can still derive value from this module – that is – they value the compiler, lint configs and the tooling; then I think we should let them.

"Opinionated by default; not inviting customization; but ultimately allowing it" is the philosophy I would like to follow.

[JustinBeckwith]

I can get behind that :)