Page MenuHomePhabricator

Decide how and where to describe ResourceLoader modules
Open, LowPublic

Description

The purpose and use cases of individual ResourceLoader module bundles are rarely documented, which makes large JS codebases hard to understand and navigate. This is exacerbated by the pressure to have huge modules to keep the size of the start module down. Having a standard place to put that documentation to would help; the simplest solution would be a description field in $wgResourceModules module definitions, which would be ignored by ResourceLoader and would merely be there for the reader's benefit.

Technically this is already possible (ResourceLoaderFileModule at least ignores unknown fields in the definition) but having an agreed-upon convention would be nice.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Krinkle renamed this task from Add a description field to ResourceLoader modules to Decide how and where to describe a ResourceLoader module .May 12 2020, 5:21 PM
Krinkle triaged this task as Low priority.
Krinkle updated the task description. (Show Details)
Krinkle moved this task from Inbox to Accepted Enhancement on the MediaWiki-ResourceLoader board.

For MediaWiki core we do this with simple code comments in Resources.php. See the mediawiki.misc-authed-ooui bundle for example.

For extensions, I suppose extension.json makes sense. On the other hand, writing more than one line of text in JSON is not a great developer experience.

Are some teams doing that already? If so, I wouldn't mind if we start by formalising that indeed as @Tgr suggests.

Are some teams doing that already?

Not that I'm aware. We do documentation similarly in the extension.json configuration section or in EventLogging schema pages, for example. (And yes, it's not a great developer experience. Still a lot better than nothing, though.)

Krinkle renamed this task from Decide how and where to describe a ResourceLoader module to Decide how and where to describe RourceLoader module s.May 27 2020, 9:40 PM
Krinkle renamed this task from Decide how and where to describe RourceLoader module s to Decide how and where to describe RourceLoader modules.
Aklapper renamed this task from Decide how and where to describe RourceLoader modules to Decide how and where to describe ResourceLoader modules.Jun 16 2020, 5:29 PM

In addition to the example @Tgr gave it seems like this would also have helped @Urbanecm_WMF on T344925

@Tgr allowing a @private or @stable property key in ResourceLoader modules would be very helpful here in addition to the existing deprecated key (which also seems like good preparation for T225842).

I would expect modules that are designed for reuse e.g. mediawiki.api to have a stable tag in their definition. This would also be helpful addition to https://www.mediawiki.org/wiki/Stable_interface_policy/Frontend

Example patch:

diff --git a/resources/Resources.php b/resources/Resources.php
index 90a31a26ddb..86265eb1398 100644
--- a/resources/Resources.php
+++ b/resources/Resources.php
@@ -696,6 +696,7 @@ return [
 		],
 	],
 	'mediawiki.api' => [
+		'@stable' => 'For use in gadgets, extensions and skins.',
 		'scripts' => [
 			'resources/src/mediawiki.api/index.js',
 			'resources/src/mediawiki.api/rest.js',
@@ -1972,6 +1973,7 @@ return [
 		],
 	],
 	'mediawiki.special' => [
+		'@stable' => 'For use inside Special pages only.',
 		'styles' => [
 			'resources/src/mediawiki.special/special.less',
 			'resources/src/mediawiki.special/apisandbox.css',
@@ -1993,6 +1995,7 @@ return [
 		],
 	],
 	'mediawiki.special.apisandbox' => [
+		'@private' => 'Only for use inside Special:ApiSandbox',
 		'localBasePath' => MW_INSTALL_PATH . '/resources/src/mediawiki.special.apisandbox',
 		'remoteBasePath' => "$wgResourceBasePath/resources/src/mediawiki.special.apisandbox",
 		'styles' => 'apisandbox.less',

I think '@stable' => 'For use inside Special pages only.' mixes two different things (stability and where to use) in a way that makes it ambiguous (does it mean it should only be used on special pages, or that it's OK to use elsewhere but you should not have any expectations of B/C)? But yeah, some kind of stability indicator seems useful.

Another possible approach would be to have a documentation library like resources/docs and for every module it would be required to have <modulename>.js in that directory, with nothing but a docblock in it. That would be a little more IDE- and documentation generator friendly, maybe, although less obvious.