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 <jrobson(a)wikimedia.org> 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 <bd808(a)wikimedia.org
<javascript:;>> wrote:
On Wed, Jul 22, 2015 at 12:24 PM, Daniel Werner
<daniel.a.r.werner(a)gmail.com <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/r…
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 <bd808(a)wikimedia.org
<javascript:;>>
[[m:User:BDavis_(WMF)]] Sr Software Engineer
Boise, ID USA
irc: bd808 v:415.839.6885 x6855
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org <javascript:;>
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org <javascript:;>
https://lists.wikimedia.org/mailman/listinfo/wikitech-l