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
