search

microsoft / sarif-sdk

.NET code and supporting files for working with the 'Static Analysis Results Interchange Format' (SARIF, see https://github.com/oasis-tcs/sarif-spec)
Other
195 stars 93 forks source link

One .editorconfig to rule them all #2145

Open ghost opened 4 years ago

ghost commented 4 years ago

It would be nice if we could share an .editorconfig among all our repos. Could it live in its own repo, incorporated as a submodule into other repos? Not sure how that would work if .editorconfig has to live at the root of each repo, but perhaps a link?

@michaelcfanning @GabeDeBacker @eddynaka

michaelcfanning commented 4 years ago

.editorConfig is valid for any directory or any of its parents.

personally, i'm not sure I'd pursue this for this specific scenario only. the idea becomes more interesting if it included a bundle of other repo standardizations (such as a common set of supporting build scripts, nugt.exe clients, targets files that drive build/test/packaging).

note that a NuGet package can run arbitrary code that copies files to various locations. so the very easy way to get what you describe here is simply to package the .editorConfig in a nuget package that copies the file alongside the SLN when a reference is added to it.

that's not really what NuGet references are for, so a bit kludgy. you could imagine using a submodule as you say, which would contain all relevant content. that repo could have an install or refresh script which would move files from the submodule directory to other upstream locations in the repository. or you could install the submodule to a directory named \scripts\ which ended up serving as that store (but could also have other content which is copied around). the submodule approach comes with all the inconveniences particular to them, of course.

ghost commented 4 years ago

All good points and good options. (I did consider the possibility that this repo could have more project-standardizing stuff in it.)