Note that as part of https://phabricator.wikimedia.org/T114457 I'm experimenting with distributing mediawiki-core itself as an npm-installable package. It ought to be possible to package up extensions, including Parsoid and VE, using npm as well. --scott
On Thu, Nov 5, 2015 at 11:32 AM, Trevor Parscal <[email protected]> wrote: > The flat approach to NPM is a game changer for us, and a Bower killer. > > Timo? Had a lot of insight at the time, I'd like to see him be invoked in > this decision. Any thoughts Timo? > > - Trevor > > On Thursday, November 5, 2015, Jon Robson <[email protected]> wrote: > > > 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] > > <javascript:;>> wrote: > > > On Wed, Jul 22, 2015 at 12:24 PM, Daniel Werner > > > <[email protected] <javascript:;>> 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] > > <javascript:;>> > > > [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA > > > irc: bd808 v:415.839.6885 x6855 > > > > > > _______________________________________________ > > > Wikitech-l mailing list > > > [email protected] <javascript:;> > > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > > _______________________________________________ > > Wikitech-l mailing list > > [email protected] <javascript:;> > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > -- (http://cscott.net) _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
