On 20 Nov 2014, at 01:48, S Page <[email protected]> wrote:
> Speaking of overzealous rules, The Flow rubocop job was failing on its
> Gemfile:
> 02:53:31 Gemfile:1:1: C: Missing space after #.
> 02:53:31 #ruby=ruby-2.1.1
> 02:53:31 ^^^^^^^^^^^^^^^^
> 02:53:31 Gemfile:2:1: C: Missing space after #.
> 02:53:31 #ruby-gemset=Flow
> 02:53:31 ^^^^^^^^^^^^^^^^^
> but all our Gemfiles are written this way.
>
> I stole the fix from CirrusSearch/.rubocop.yml :
>
> Style/LeadingCommentSpace:
> Exclude:
> - Gemfile # RVM doesn't recognise spaces after the #s
> and now the mwext-Flow-bundle-rubocop CI job passes.
>
> Is there a way MediaWiki extensions can share common configuration and
> dev_scripts like this? Maybe extensions/shared, or extensions/Mantle/defaults
>
>
This has been suggested in the past for jshint and jscs configuration, which I
recommended against at the time. And I think that was for the best.
The downside of centralising configuration affecting tests or style checks is
the inability to iterate, improve, extend or change pretty much anything.
Whenever a change is made existing code either has to be passing the new
version already or various repositories will suddenly find themselves with a
failing build for an unrelated commit in their master branch.
That doesn't mean projects should have different configuration. Merely that
it's kept in the individual repository. And updated virally as new rules are
embraced by our conventions. Also allows project to adopt a style checker with
fewer rules at first and integrate stricter rules in smaller chunks.
Among the advantages is also that it allows one to run checks from the command
line on your local machine with a generic utility without needing special
knowledge (e.g. "my-tool --config .my-config" will consistently work).
Text editor plugins also need to detect the configuration in the working
directory of said project. E.g. Sublime Text jshint or jscs plugins wouldn't
work otherwise[1].
For jscs we've done a combination of central and local. We centralised the
coding style (it's upstream in node-jscsp[2] as preset "wikimedia"). But we
don't have any of the downsides of central config because it's still specified
by the local config (jscsrc: { "preset": "wikimedia"}), and the version of the
node-jscs application is specified in package.json.
For jshint we never used a central config. The file is small enough.
It seems robocop requires quite verbose configuration making it less attractive
to maintain in individual repositories. Perhaps we can inherit some kind of
base config with only minor local changes, or even upstream our conventions,
like I did for jscs.
-- Krinkle
[1] One could set global default to a clone of the Wikimedia style but that
still means you'll break master of other repos, and you'd have to keep that
clone up to date (instead of coming along with the git clone of said project).
And wouldn't scale well when contributing to non-Wikimedia projects.
[2] https://github.com/jscs-dev/node-jscs_______________________________________________
QA mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/qa
