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 <tparscal(a)wikimedia.org>
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 <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?
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
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l