Page MenuHomePhabricator

Special:Version should include version numbers of JS resources like jQuery
Closed, ResolvedPublic

Description

Currently there is no easy way to check what version of JavaScript libraries (like jQuery) are provided.

For jQuery, it can be determined from the documentation at https://www.mediawiki.org/wiki/JQuery .

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 12:06 AM
bzimport set Reference to bz32892.
bzimport added a subscriber: Unknown Object (MLST).

For jQuery the easiest way is probably to fill it in from JS; $.fn.jquery holds the version number.

Can we be careful about adding things here? I remember the last time we went overboard with adding version numbers...

I don't remember last time... or was it trying to add many OS packages to the list? Just having the jQuery version number would suffice for me.

It started with just adding one version number. And before you knew it, we were shelling out to imagemagick and diff3 to put all kinds of version numbers in that little table.

It is a slippery slippery slope :)

I could sorta see the benefit.. But we could also have a table on mw.org that for each MW version, we listed versions of major libraries (jQuery, jQuery.ui) that are released with MediaWiki

Yay, documentation!

(In reply to comment #4)

It started with just adding one version number. And before you knew it, we were
shelling out to imagemagick and diff3 to put all kinds of version numbers in
that little table.

It is a slippery slippery slope :)

We could maybe add only versions of the code that the users load/use/execute directly (what is there besides JS?) and leave all back-end dependencies hidden?
jQuery can throw errors directly to the user and custom JavaScript depends on it so again what users do is directly affected by it, unlike category sorting, diffs, image scaling and so on. Also, one could supposedly guess the rest from the OS info, but not jQuery?

(In reply to comment #2)

Can we be careful about adding things here? I remember the last time we went
overboard with adding version numbers...

For what is worth, this is how https://en.wikipedia.org/wiki/Special:Version looks today:

MediaWiki 1.23wmf10 (7a69cda)
PHP 5.3.10-1ubuntu3.9+wmf1 (apache2handler)
MySQL 5.5.34-MariaDB-1~precise-log
Elasticsearch 0.90.10
LuaSandbox 1.8-1
Lua 5.1.4

If there is an agreement on this request, then it could be marked as EASY.

I would like to know the status of this bug.

There have been no news for the last three years reported in this task, hence the described issue very likely still exists (the task status is "open" (in the upper left corner).).
Nobody works on this.

I have added jQuery version.
I used jQuery.fn.jquery to find the version, which seems to be 1.11.3.

Here's the screenshot

Screenshot for jq.png (720×1 px, 200 KB)

@Harjotsingh Would you like to upload your change to our code review system gerrit? That would make commenting (and especially merging) much easier. You can find an introduction how to use gerrit and setup your local environment to submit patches from the information page on mediawiki.org.

@Florian Uploaded change to gerrit.
How to change status to needs-review ?

Change 274773 had a related patch set uploaded (by Florianschmidtwelzow):
Added jQuery Version

https://gerrit.wikimedia.org/r/274773

Change 274773 abandoned by Harjotsingh:
Added jQuery Version and Convert space after § to non-breaking spaces

Reason:
duplicate

https://gerrit.wikimedia.org/r/274773

Change 275160 had a related patch set uploaded (by Harjotsingh):
Added jQuery version to Special:Version

https://gerrit.wikimedia.org/r/275160

Change 275160 abandoned by Harjotsingh:
Added jQuery version to Special:Version

Reason:
Duplicate

https://gerrit.wikimedia.org/r/275160

Change 275160 restored by Harjotsingh:
Added jQuery version to Special:Version

https://gerrit.wikimedia.org/r/275160

For jQuery it may seem easy, but what about other libraries? SpecialVersion would easily end up very cluttered.
Of course the long-term solution is to use a real package manager...

For jQuery it may seem easy, but what about other libraries? SpecialVersion would easily end up very cluttered.

It is already very cluttered. But most people stop reading after the first table, and anyone who goes further is likely preferring comprehensiveness where possible. I don't see a problem with adding another table to Special:Version with more useful information. I would rather load a webpage than hunt around in each JS library to figure out its version; old age has set in, or something...

The JS versions could even be added by JS , as anyone loading Special:Version without JS is very unlikely to care about the versions of each JS library. ;-)

For that matter, this could be initially developed as a gadget, and the need for this in core re-evaluated if the gadget is very popular.

Of course the long-term solution is to use a real package manager...

MediaWiki uses Composer. I am not sure if you are implying that it isnt 'real'.
Perhaps MediaWiki could use composer for its JS components also, such as jquery. Could be it is already on the roadmap for MediaWiki-ResourceLoader to use packaged versioned resource loading - or maybe it already does , but I havent seen real versions in extension.json's.

Composer installs all package files inside the vendor directory.Composer does not address is the installation of the asset files.Therefore its not responsible for jQuery and JS components.
There exists Composer Asset Manager Plugin which can be used to install JavaScript libraries, CSS files, images, etc..

I don't see a problem with adding another table to Special:Version with more useful information.

I don't either. You can see, however, that the proposed patch adds a new entry to the "Installed software" table.

The JS versions could even be added by JS , as anyone loading Special:Version without JS is very unlikely to care about the versions of each JS library. ;-)

That still requires loading every library on the special page, including perhaps conflicting ones, and knowing where the version number is exposed.

For that matter, this could be initially developed as a gadget, and the need for this in core re-evaluated if the gadget is very popular.

Do you see demand for it?

Perhaps MediaWiki could use composer for its JS components also, such as jquery.

MediaWiki uses NPM for development dependencies. I think it's much more popular than Composer for JavaScript libraries.

Change 275160 abandoned by Thiemo Kreuz (WMDE):
[mediawiki/core@master] Added jQuery version to Special:Version

Reason:

https://gerrit.wikimedia.org/r/275160

If someone is interested in picking this up, I'd suggest the following:

  • Rename "Installed libraries" to "Installed server-side libraries".
  • Add "Installed client-side libraries" section, with its contents derived from foreign-resources.yaml.
    • The object key would be the package name.
    • Introduce a required property to foreign-resources: meta.license (SPDX identifier)
    • Introduce two additional optional properties: meta.homepage, meta.version
    • Rendered e.g. as: "jquery (3.4.1, MIT)", falling back to "jquery (MIT)"

Change 821306 had a related patch set uploaded (by Simon04; author: Simon04):

[mediawiki/core@master] Add client software to Special:Version

https://gerrit.wikimedia.org/r/821306

Screenshot for the submitted patch:

Screenshot 2022-08-08 at 22-09-36 Version - simon04.png (931×722 px, 107 KB)

Change 821306 merged by jenkins-bot:

[mediawiki/core@master] Add client-side libraries to Special:Version

https://gerrit.wikimedia.org/r/821306

Reedy removed a project: Patch-For-Review.
Reedy subscribed.

v1 of this has landed. There's definitely some followup and improvements to be done, but created as parent tasks...

Thanks!