On Wed, Jul 22, 2015 at 12:24 PM, Daniel Werner <daniel.a.r.wer...@gmail.com> wrote: > 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/resources/vendor/jquery.event.special.eachchange.js
Option 4 was discussed last October as part of the Librarization project [0]. At the time the front end standards group wasn't ready to pick a winner in the javascript packaging landscape. They did want to revisit that in 3-6 months however so maybe it is time to find someone to look into the various options and their pros and cons again? [0]: https://phabricator.wikimedia.org/T807 -- Bryan Davis Wikimedia Foundation <bd...@wikimedia.org> [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA irc: bd808 v:415.839.6885 x6855 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
