Hey,
I just wanted to check in about the status of enabling JavaScript package
management usage in MediaWiki. I am basically talking about an equivalent
for JS to what we have with Composer for PHP.
Real-world example:
The "data-values/value-view" package[0] is defining
"jquery.event.special.eachchange.js":
ValueView/lib/jquery.event/jquery.event.special.eachchange.js
Now, recently I needed the same functionality in one of my extensions, so
I just copied it over. [1]
I know that this is the worst way one could do this, but as far as I can
see we don't have that much of a choice right now. Here are the alternative
options I can see:
Moving "jquery.event.special.eachchange.js" out of the
"data-values/value-view" package into its own "WMDE/jquery-eachchange"
package...
1. ... and using it in my extension via composer.
+ pro: two or more extensions or other packages requiring this package
will still result in having only one MW-wide installation..
- con: requires MW specific code which is actually not related to the
MW-independent package to feed the resource loader.
- con: using Composer to manage pure JavaScript packages! Uuuh, ugly!
2. ... and having a build step in other packages using the package, pulling
the "WMDE/jquery-eachchange" somewhere into the file structure of the
packages/extensions using it.
+ pro: don't need to abuse composer, we can use "npm", "Bower" or any
other arbitrary JS package manager here.
- con: got to tell resource loader somehow... (didn't think so much about
that yet)
- con: if more than one extensions or other packages require this package
we still end up with the same code twice or more often in one MW
installation.
3. Combining 1 and 2: Start with 2, using a JS package manager. Then going
to 1, creating a composer package and pulling the "WMDE/jquery-eachchange"
package in via some build script.
+ pro: The two pros from 1 + 2
+ pro: ^^
- con: still got to tell resource loader somehow...
- con: Overhead; We now create two packages where the Composer one is
just a bridge to the MW-world, still polluting packagist.org. Still kind of
ugly and more effort for publishing a package and therefore potentially
scaring programmers away from doing so since they've got better things to
do than doing work that could be automated.
I have not seen Approach 2 and 3 yet. Though I could imagine that the
VisualEditor team has used something like that.
Approach 1 is the way the "data-values/value-view" package itself is being
handled. And that package should actually be a MW independent pure JS
package but right now it contains MW specific code and uses composer for
distribution!
There is still another option but that had to be properly implemented:
4. Choose one native JS package manager for now and go with it (add support
for others later perhaps). Integrate it properly with MW (resource loader
to begin with), document how to use it and finally distribute JS code
coming from the MW world but useful for other projects in a way where it
can actually be used in a non-MW context.
This has already been bugging me when working on Wikidata. Now I'd like to
reuse some of the code I have written there without spending hours and
hours with option 3 because there should be support for option 4 rather
sooner or later.
So I am wondering; Does anyone have any thoughts, any alternatives perhaps
or is there any roadmap on anything like the option 4 that I have shown?
Cheers,
Daniel
[0]: https://packagist.org/packages/data-values/value-view
[1]:
https://github.com/DanweDE/mediawiki-ext-UserBitcoinAddresses/blob/master/r…
Hi, I'd like to present a new RFC for your consideration:
https://www.mediawiki.org/wiki/Requests_for_comment/Minifier
It is about how we can shave 10-15% off the size if JavaScript
delivered to users.
Your comments are highly welcome!:)
--
Best regards,
Max Semenik ([[User:MaxSem]])
Hi,
Thanks to the hard work of a lot of different people, PHP CodeSniffer is
now voting on all MediaWiki core patchsets! It checks for basic code
style issues automatically so new contributors (and experienced ones!)
can fix basic issues without a human needing to point them out.
I added some brief instructions to [1] on how to run it locally, or you
can read the jenkins output.
There are still a few code style rules that are disabled, [2] is
tracking fixing those issues.
Please file any bugs or feature requests in the MediaWiki-CodeSniffer[3]
project on Phabricator.
[1] https://www.mediawiki.org/wiki/Continuous_integration/PHP_CodeSniffer
[2] https://phabricator.wikimedia.org/T102609
[3] https://phabricator.wikimedia.org/tag/mediawiki-codesniffer/
-- Legoktm
Consensus was reached in the first discussion regarding the intro,
"Principles", and "Unacceptable behavior" sections. See
https://www.mediawiki.org/wiki/Talk:Code_of_conduct_for_technical_spaces/Dr…
.
However, while that was being discussed, several of us made changes to
these sections. In the future, we need to avoid this (to avoid endless
discussion).
Thus, in the future I'll send out two separate announcements, one for
"last call to work on these sections" and one for "consensus discussion
for these sections".
However, this time, that wasn't done. So I want to give people a chance
to weigh in on whether we should accept the changes that were made
during the first discussion.
Thus, there is a new discussion at
https://www.mediawiki.org/wiki/Talk:Code_of_conduct_for_technical_spaces/Dr…
.
This will only last a week. I expect to close it October 6th.
Thanks,
Matt Flaschen
Jack Phoenix and I were considering doing a tech talk about how to make
a MediaWiki skin. Would there be any interest in this? What would you
folks want to see from such a talk?
-I
If you are planning on proposing a session for the Wikimedia Developer
Summit, remember that the deadline for new proposals is *October 2*, in a
couple of days.
For this milestone we are only requesting draft tasks created in
Phabricator and associated to #Wikimedia-Developer-Summit-2016. The
following deadlines are
1. By *6 Nov 2015* all Summit proposals must have active discussions and
a Summit plan documented in the description. Proposals not reaching this
critical mass can continue at their own path out of the Summit.
2. By *4 Dec 2015* all the accepted proposals will be published in the
program. Strong candidates might be scheduled before.
https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit_2016#Submissions_…
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Hello,
I was looking at some statistics of school students ( < 17 years )
participation from my state in Open Source program like Google Code In,
and it is ~0. The Government here has initiated a project to distribute
Raspberry Pi for school students[1], and it would be great to have them
setup a Mediawiki development environment with the Pi so that they can
contribute.
The Pi's have 1 Gig ram, and I got a docker container of Ubuntu ( arm )
running smooth. There are few blockers to install MW-Vagrant or the LXC
container, which are:
1. <bd808> The puppet config for mw-vagrant needs a 64-bit Ubuntu 14.04
container to run inside
2. <bd808> mv-vagrant has a lot of bells and whistles that make it
really want a lot of ram and CPU
3. <bd808> hhvm is too ram hungry
and lot more. The other option will be to setup a LAMP stack, which would
need to be automated ( need scripts ). I wanted to know if this porting
would be feasible, and worth the development hours, and specifically - if
someone is interested.
[1]
http://gadgets.ndtv.com/others/news/kerala-launches-learn-to-code-pilot-wil…
Thanks,
Tony Thomas <http://blog.tttwrites.in/>
ThinkFOSS <http://www.thinkfoss.com>
*"where there is a wifi, there is a way"*