It's been a year now, over 3-6 months. Volker can this be given a priority in the next frontend standards meeting. I think the lack of any standard is extremely damaging to the project.
On Wed, Jul 22, 2015 at 4:21 PM, Bryan Davis <[email protected]> wrote: > On Wed, Jul 22, 2015 at 12:24 PM, Daniel Werner > <[email protected]> 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 <[email protected]> > [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA > irc: bd808 v:415.839.6885 x6855 > > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
