Open leobalter opened 8 years ago
@arthurvr is this something you could help with?
A list of repos with config files in use, highlighting the (in)consistencies would be useful.
Some more files to add to the list: .csslintrc
, .gitignore
, .gitattributes
, .travis.yml
(sudo: false
!)
On the dev leads meeting the idea was brought up to edit these files in one repo, then use bower/npmcopy to add/update them in individual repos. That would still require commits to each repo, but might still make it quite a bit easier to mange. Using bower/npmcopy, each repo can decide which files to actually include, so a project without CSS won't need to have a .csslintrc
.
Regarding .editorconfig
, we need to check if we need an exception to allow trailing whitespace in markdown files, since regular linebreaks are converted to spaces. Maybe we should use the trailing-backslash style instead, but that depends on our markdown converter actually support that.
Note from @arthurvr from on jquery/api.qunitjs.com#115: The package.json there uses 2 spaces for indent. That applies to other repos as well, since we use npm version
which always reformats with 2 spaces. Doesn't look like that's ever going to change: https://github.com/npm/npm/pull/3062
Regarding the centrally managed repo: If we have that, we could also include those files in this repo, to show the "current" config files on contribute.jquery.org, via @partial: https://github.com/jquery/grunt-jquery-content#partial
There haven't been any objections, so I think we're good to move forward on this. Is anyone interested in leading this?
I created a repo on the jquery-support org for this: https://github.com/jquery-support/dotfiles
Would be great if someone could do the initial collection of the various config files. I can help with getting them published and integrated elsewhere.
After a discussion on https://github.com/jquery/api.qunitjs.com/pull/114#issuecomment-150332207, it sounds we might use some examples of our kickstart configuration files we already use on most projects.
That might include, not exclusively:
.editorconfig
As the style guides, these might be strongly enforced, but breaking some rules - to explore to new standards - are welcome.