Page MenuHomePhabricator

Investigate javascript library management options
Closed, DeclinedPublic


Investigate the options available in the javascript library management
space and determine if using any existing system would allow results
similar to the results that we are aiming for in the PHP space. These
goals are broadly:

  • To make managing the use of externally developed libraries easier by introducing a method to explicitly declare dependencies and their versions
  • To promote expanding the use of code developed to support MediaWiki and the Wikimedia Foundation goals beyond the MediaWiki user community where the software has a broader use case than internal MediaWiki business logic

Ideally we would find a system that can be seamlessly integrated with Composer to provide a unified workflow for MW users.

A quick survey has found these possible options:

Event Timeline

bd808 raised the priority of this task from to Medium.
bd808 updated the task description. (Show Details)
bd808 added a project: Librarization.
bd808 changed Security from none to None.
bd808 removed a subscriber: Unknown Object (MLST).
bd808 added subscribers: ori, TrevorParscal, Krinkle and 2 others.
bd808 added a subscriber: bd808.

@TrevorParscal has suggested that this discussion be made a topic for an upcoming weekly meeting of the front end standards group.

I looked into the two composer-npm bridges linked above:

  • composer-npm-bridge
    • Requires you have npm installed, you put the dependencies inside a package.json file. I think it's just using composer as a wrapper around npm. Using npm install directly produced the exact same result.
  • composer-asset-plugin
    • Requires installing it globally with composer. IMO that's a dealbreaker, there's a PR open to fix that though. I didn't test this one.

Good preliminary discussion today in the weekly front end standards group meeting. These key questions were identified:

  • Should we or should we not have package management for javascript?
  • If we use one, which one? (npm or bower)
  • What does this mean for MediaWiki tooling complexity?
  • Should guidelines be established for what should be considered when adding dependencies to MediaWiki?

These questions will be the topic of follow up discussions.

bd808 claimed this task.

Following additional discussion in the 2014-10-31 Front end standards group meeting, the consensus is that the initial focus should be on standardizing practices for developing/extracting libraries and ensuring they are properly managed as independent or at least semi-autonomous open source projects rather than package management.

At this time the future of Resource Loader and javascript package management standards in general are too uncertain to make a decision on using an automated process for importing the resulting libraries back into MediaWiki. The group would like to revisit this topic in 3-6 months when currently active discussions about the future feature set of npm have been resolved.

We talked about this in the FE stds group meeting yesterday. Here are the minutes from that bit:

  • Trevor: npm has changed quite a bit and *could* meet our needs now
  • Timo: issues with npm have mostly been resolved (not perfect but good) Issues:
    • Dependencies: doesn't figure out browser support. Indirect dependencies.
    • Resource Loader updates
  • Volker: this is a big architectural issue that needs to be addressed from multiple points of view and probably going into an RfC
  • Timo: (require and exports handling)