Page MenuHomePhabricator

Extension.json format version 2 does not support @note in configs
Closed, ResolvedPublic

Description

The docs say:

It is possible to include some documentation directly in the extension.json file as well. Extension registration ignores any key in extension.json starting with '@' in the top-level structure or under config, so you can put comments in those parts of the JSON file.

However, it is not true for v2 format. If you try to add @note in v2 extension.json, you get:

Illegal string offset 'value'

Looking at the code in ExtensionProcessor.php, it is easy to see why: extractConfig1() has checks for @:

if ( $key[0] !== '@' ) {
	$this->addConfigGlobal( "$prefix$key", $val, $info['name'] );
}

but extractConfig2 has no such checks.

I think these checks should be ported to v2 too, since having notes in the config can be useful. But in case this is impossible, the docs should clearly state this is not the case for v2 in Mediawiki.

Event Timeline

@ was used for documentation but v2 has its own documentation field. Are you thinking of some note-making use case distinct from documentation? `"doc": "blah blah (note: bleh)" seems simpler.

@ was used for documentation but v2 has its own documentation field

For configs, but not for top scope IIRC. In any case, docs about specific value and docs about config sections (such as "the configs below deal with fulltext search profiles") can be different.

Are you thinking of some note-making use case distinct from documentation

Well, I can live without notes in docs, as long as notes outside docs work, I guess, though it's a bit confusing - in v1, @note worked in both places, in v2 @note works only in one place, despite what the docs say. So I'd like to figure out what it would be going forward and if @note in configs is not going to be supported anymore, it should be clearly stated in Mediawiki as no longer recommended way to do docs.

Well, it's definitely not the recommended way. The doc property can be introspected and internationalized and will eventually be exposed on some admin interface.

Smalyshev claimed this task.

Ok, I've updated the docs accordingly. I think then this can be resolved.