Developer Wishlist/2017/Developer Environment

Integrate a modern php REPL shell with MediaWiki
Currently MediaWiki provides a custom console via eval.php, which is integrated with the wiki's environment but otherwise rather poor (no proper readline support, no fatal error handling, the P part of REPL is missing, no tab autocompletion, no reflection...). Vagrant provides phpsh / hhvmsh which is somewhat better but still mediocre. It would be nice to replace these with a great REPL like PsySH or Boris.

Support (T117661)

 * 1) &mdash; Mainframe98  talk 09:31, 6 February 2017 (UTC)
 * 2) Osnard (talk) 12:53, 6 February 2017 (UTC)
 * 3) Jdforrester (WMF) (talk) 16:21, 6 February 2017 (UTC)
 * 4) &mdash;  MusikAnimal  talk  16:42, 6 February 2017 (UTC)
 * 5) Amir E. Aharoni (talk) 16:58, 6 February 2017 (UTC)
 * 6) SIMOKHALIL (talk) 03:54, 7 February 2017 (UTC)
 * 7) Nikerabbit (talk) 07:59, 7 February 2017 (UTC)

Choose a recommended IDE for MediaWiki and maintain a plugin for it
Good IDE integration convenient for everyone but especially helpful to new contributors who are not experienced coders - they have to learn a thousand new things from code review / distributed version control workflows to security back practices, and if we can avoid adding "learn how to tweak your IDE configuration" to that pile, we can make the learning curve significantly smoother.

A well-integrated IDE would
 * ensure that the right coding conventions are followed
 * do some of the CI checks in a much more user-friendly way (banana, autoloading etc.)
 * provide docs / typing / code completion / clickthrough navigation for systems which IDEs cannot figure out by default (e.g. hooks, global variables, extension-provided services, ResourceLoader modules)
 * maybe show docs/help from mediawiki.org
 * maybe warn when some MediaWiki best practices are not used (e.g. extension with PHP endpoint)

This does not mean that MediaWiki would be optimized to work with one IDE to the detriment of others, but it's nice to have a default.

PHPStorm integration already seems to have some momentum behind it, but which IDE we focus on is secondary to agreeing to focus on a single one.

Support (T156873)

 * 1) Info-farmer (talk) 05:17, 6 February 2017 (UTC)
 * 2) &mdash; Mainframe98  talk 09:33, 6 February 2017 (UTC)
 * 3) --Шухрат Саъдиев (talk) 11:31, 6 February 2017 (UTC)
 * 4)  ·addshore·  talk to me! 12:15, 6 February 2017 (UTC)
 * 5) Miriya52 (talk) 21:19, 6 February 2017 (UTC)
 * 6) Daniel Mietchen (talk) 22:22, 6 February 2017 (UTC)
 * 7) Info-Screen (talk) 05:37, 7 February 2017 (UTC)
 * 8) Liridon (talk) 12:11, 7 February 2017 (UTC)

Integrate a modern debug/error display tool into MediaWiki
The MediaWiki ecosystem has some highly sophisticated loggin/debugging/error reporting tools such as the ELK stack, but they are nontrivial to set up and an effort to use (you need to go to the aggregation site and search for your error or log message, instead of just having it right on the wiki page where the error happened). It would be nice to integrate some modern error display / debug tool into MediaWiki for casual development - probably as an extension, since such tools tend to be insecure. A few possibilities:
 * kint
 * Ladybug
 * whoops

Support (T111731)

 * 1) Ladsgroup (talk) 09:56, 6 February 2017 (UTC)
 * 2) Frettie (talk) 10:03, 6 February 2017 (UTC)
 * 3) Amir E. Aharoni (talk) 13:47, 6 February 2017 (UTC)
 * 4) Jdforrester (WMF) (talk) 16:21, 6 February 2017 (UTC)
 * 5) Daniel Mietchen (talk) 22:23, 6 February 2017 (UTC)
 * 6) &mdash;  MusikAnimal  talk  22:42, 6 February 2017 (UTC)
 * 7) &#91;&#91;kgh&#93;&#93; (talk) 23:24, 6 February 2017 (UTC)
 * 8) Santhosh.thottingal (talk) 03:31, 7 February 2017 (UTC)
 * 9) MSchottlender-WMF (talk) 05:29, 7 February 2017 (UTC)
 * 10) Liridon (talk) 12:11, 7 February 2017 (UTC)
 * 11) BSitzmann (WMF) (talk) 19:10, 7 February 2017 (UTC)
 * 12) MHolloway (WMF) (talk) 22:00, 7 February 2017 (UTC)

Problem
Continuous Integration is hard to set up for repositories in the Wikimedia environment. Often this will require changes to the  repo (e.g. editing a huge YAML file) and whitelisting of users (who may otherwise be unable to trigger some Jenkins jobs via Gerrit).

Proposed solution
Travis CI et similia only require a simple YAML file in the root directory of each code repository. Supporting such model can greatly streamline the addition of CI to repositories managed by small volunteer teams, decrease reliance on third-party services and ease the work of the few employees dedicated to CI infrastructure.

I discussed this on #wikimedia-releng and mmodell thought it was a nice idea, he is the one who came up with the name for the file. But this will help us customize it per repo without needing to create a separate job.

paladox: it would be cool to do something similar to travis, with a test config file, indeed.

What we will do is have a major improvement over .travis-ci which will allow us to define multiple tests at the same time instead of being limited to 1.

An example on how it will look

This is a mock and will need improvements to support extending our tests without making it complex.

Support (T145669)

 * 1)  ·addshore·  talk to me! 12:16, 6 February 2017 (UTC)
 * 2) Krinkle (talk) 19:27, 6 February 2017 (UTC)
 * 3) Nikerabbit (talk) 08:01, 7 February 2017 (UTC)
 * 4) MHolloway (WMF) (talk) 22:04, 7 February 2017 (UTC)