We should choose something, any of them is better than nothing, and manually copying files.
My vote goes to npm, now that it tries (in v3) its best to flatten the node_modules folder. See the changelog ( https://github.com/npm/npm/releases/tag/v3.0.0)
*Flat, flat, flat!*
Your dependencies will now be installed *maximally flat*. Insofar as is
possible, all of your dependencies, and their dependencies, and THEIR dependencies will be installed in your project's node_modules folder with no nesting. You'll only see modules nested underneath one another when two (or more) modules have conflicting dependencies.
And it is the biggest JS package manager.
On Thu, Jul 23, 2015 at 1:21 AM, Bryan Davis bd808@wikimedia.org wrote:
On Wed, Jul 22, 2015 at 12:24 PM, Daniel Werner daniel.a.r.werner@gmail.com 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...
- ... 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!
- ... 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.
- 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:
- 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
[1]:
https://github.com/DanweDE/mediawiki-ext-UserBitcoinAddresses/blob/master/re...
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@wikimedia.org [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA irc: bd808 v:415.839.6885 x6855
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l