Wikipedia:ガジェット/提案

このページでは SpBot による過去ログ化が行われています。解決済みの節に {{Section resolved|1=--~~~~}} というテンプレートを設置して過去ログ化を提案すると、その節は 7 日後に過去ログ化されます。

関数ライブラリのガジェット化提案

今まで一括系ガジェットを開発する中で、特にテンプレートパーザーなどの関数は同じものを複数ガジェット間で使っていました。この状態だとその関数に手を加えたい時に全てのガジェットを個別に修正する必要があるのでどうにかしないと、と思っていたのですが、ようやくライブラリスクリプトがある程度かたちになりました。

• MediaWiki:Gadget-WpLibExtra.js

前から開発すると言っていたMassDeleteをまず、このライブラリを使って作ろうと思っているので、このスクリプトの正式なガジェット化を提案します。GitHubにライブラリのdocumentationもあります。例として、F12でコンソールを開いて以下のコードをコピペ+Enterしてみてください。WP:AN/Iにあるテンプレートを全て抽出します。

var moduleName = 'ext.gadget.WpLibExtra';
mw.loader.using(moduleName).then(function(require) {
    var lib = require(moduleName);
    lib.load().then(function() {
        lib.Wikitext.newFromTitle('Wikipedia:管理者伝言板/投稿ブロック').then(function(Wkt) {
            if (!Wkt) return;
            var temps = Wkt.parseTemplates();
            console.log(temps);
        });
    });
});

以上、よろしくお願いします。 --Dragoniez (talk) 2023年10月4日 (水) 10:35 (UTC)

もとがTypeScriptで書かれていて、そこから自動生成した結果がこのJavaScriptのようです。他の人が変更を加えたい場合は、（TypeScriptのほうはとくに考えずに）JavaScriptのほうを直接変更していいのでしょうか？--whym（会話） 2023年10月8日 (日) 13:15 (UTC)

ウィキ上のJSを編集して頂いて差し支えありません。私の労力的にはGitHub上でプルリクエストを出してもらった方が楽と言えば楽ですが、TypeScriptファイルは編集差分を見て都度更新します。 --Dragoniez (talk) 2023年10月9日 (月) 10:47 (UTC)

TypeScriptに慣れていてコードレビューなどをする人（でDragoniezさん以外の人）はこのコミュニティにどれくらいいるでしょうか？事情を知った人だけが使うユーザースクリプトなら個人の責任でTypeScriptを導入してかまわないと思いますが、ガジェットの場合はコミュニティ全体で（仮にDragoniezさんが急にいなくなったりしても）メンテナンスする準備ができている必要があると思います。--whym（会話） 2023年10月17日 (火) 11:06 (UTC)

返信 少し考えたのですが、JSのメンテナンス自体は特段障壁のようなものは生じないのではないでしょうか。このライブラリの開発にTypeScriptを使ったのには色々と理由があり、モジュール冒頭の__extends、__assign、__spreadArray以外は通常のJavaScriptモジュールと変わらないので、on-wikiで修正を行うのも特段難しくないと思われるのと、仮に私が姿を消しても私のレポジトリの内容とon-wikiのJSファイルの内容に差異が生じるのみで、差分の内容もいつでも確認できますし、on-wikiのメンテナンス自体に障害はないと思います。
これは「ガジェット本体」ではなく純粋な「モジュール」なので、このモジュールを使用する (私以外の) 人に最適な開発環境を可能な限り準備できたらと思い、以下を個人的なノルマとして開発しました。

1. API documentationがあること。
2. IntelliSenseが機能すること。

根本的にこの2つはon-wikiでは実装不可能かつ、npmパッケージをいじれないと実現できないものです。つまりウィキペディアのガジェットページとは独立したものですので、これらは私が個人的に作っただけのもので、on-wikiファイルのメンテナンスには影響しません。(レポジトリの更新が滞ればこの2つの情報更新も滞りますが、ガジェット自体に手が加えられていれば「追加機能」が不便になるだけです。)

JavaScriptで上記の追加機能を実装しようとした際に生じる障害の詳細

上記「追加機能」を実装するにあたり、「ガジェットファイル自体はES5 syntaxに留める」ということが障害になったためTypeScriptを使用しています。というのも、ライブラリであるがゆえにコード自体が複数のclassを含んでおり、ES5に縛るとなるとclass A {}ではなくfunction A () {}でclassを実装する必要がありますが、後者の関数宣言でclassを実装する場合、追加機能の両方に対して実装の障害があります。現状、JavaScriptとJSDocでdoc (上記1) とd.ts (上記2) を生成しようとすると、JSDocが関数宣言型子クラスのprototypeに対してIntelliSenseを生成できません。具体的には、class A {}、class B extends A {}ではなくfunction A () {}、function B () {}でクラス継承を実装すると、JSDocの@extendsタグが現状functionで定義されたクラスを認識しないため、IntelliSenseが必ずエラーを吐くというものです。例として、以下#L24と#L30のthis.nameとhelloはany型としか認識されず、(この状態はhelliのような誤字がある時と変わらないため) 元コード自体のバグの温床となりえます。(ゆえに、TypeScriptでES6のclassを使って元コード自体は書き、ES5にトランスパイルして関数宣言型クラスに変換しています。)

/**
 * @class
 * @param {string} name 
 */
function A(name) {
	/** @type {string} */
	this.name = name;
}
A.prototype.hello = function() {
	console.log('Hello ' + this.name + '!');	
};

/**
 * @class
 * @extends A
 * @param {string} name 
 */
function B(name) { // JSDoc '@extends' is not attached to a class.
	A.call(this, name);
}
B.prototype = Object.create(A.prototype);
B.prototype.constructor = B;
B.prototype.bye = function() {
	console.log('Bye ' + this.name + '!'); // Property 'name' does not exist on type 'B'.
};

var a = new A('Alice');
var b = new B('Bill');
a.hello(); // Hello Alice!
b.hello(); // Hello Bill! - Property 'hello' does not exist on type 'B'.
b.bye(); // Bye Bill!

コンパイラを通したコードが仮にこのようなコードであった場合on-wikiでのメンテナンス性に懸念が生じるのは分かるのですが、今回MediaWiki名前空間に作成したファイル自体にメンテナンス性の懸念はあるのでしょうか。通常の可読JSと変わらないものと私は認識しています。 --Dragoniez (talk) 2023年10月24日 (火) 09:22 (UTC)

通常のJavaScriptとあまり変わらないというのは、今回たまたまあまり変わらなかったのでしょうか。一定の制限されたTypeScriptの書きかたをすると、そうなるのでしょうか。enumやnamespaceはいかがでしょうか。 --whym（会話） 2023年10月31日 (火) 09:34 (UTC)

「一括系ガジェット」とはどのガジェットですか？ 今回のモジュールの中にあるどの関数をどのガジェットが使う、といった対応表は作れますか？ それが提示されれば、共通化の意義が分かりやすくなるかもしれません。 --whym（会話） 2023年10月31日 (火) 09:34 (UTC)

@Whymさん、返事が遅れてすみません。根本的にJSで書かれたファイルとJSにコンパイルされたファイルとでは、前者には生じ得ない懸念が後者に生じうることは私自身理解したうえで、質問があります。
Whymさんの中で「メンテナンスする準備が整っていること」が何を意味するのかお伺いしてもよいでしょうか。「TSのことを特に考えずにウィキ上のJSを変更していいのか」という問いに対して「変更して頂いて問題ない」と返答させていただきました。この文脈から「メンテナンスする準備が整っていること」について返答すると、「コンパイル後の、ウィキ上で管理するJSがJSとしてメンテナンス可能か」という論点になり、これを踏まえて回答するとしたら上記のように「特段読むのには困らないJSなのでメンテナンス上は問題ないだろう」という回答になります。
一方、（このライブラリは使用していない）enumやnamespace関連から推測すると、これらは「人間が書かないようなコードにコンパイルされる」という意味でウィキ上でのJS編集に懸念が生じる、ということでしょうか。それとも、JSのスーパーセットであるTS、つまりJSにない機能を有する言語からコンパイルされたコードという事実「自体」が駄目だ、ということでしょうか。ガジェット化提案をさせていただいている以上「このライブラリをこのままガジェット化するには何が必要か」を上記の文脈のもと検討していましたが、論点がどこにあるのかいまいち分からなくなりました。今回のTSをもとにしたライブラリは、「静的型付け」と、ES5の関数宣言クラスはES6のclassとは違いprototype継承をIntelliSenseに反映できないため、「ES6をES5に変換」し、この問題を回避するためだけに使用しています。よって、懸念点が前者なのであれば私がTS特有の機能を使用しなければ解決される問題であると思いますが、後者の場合はTSを使用する限りこの提案は取り下げざるを得ない、ということになります。つまるところ、

• TSを使用している現状の状態でガジェット化の合意が可能だとしたら、私に求められることは何ですか？

「ウィキ上のJSのメンテナンス性」への配慮によりこの点がどうにかなるのであればそれに基づき対応させていただきたく思っていますが、根本的に論点がそこにはない場合、解決策を模索する行動自体が無駄になります。（なお、コンパイラを通したものをガジェットにすべきではないという結論になる場合は、このライブラリを使用予定のガジェットはすべて私が開発し他の方の編集が入っていないという事情も踏まえ、そのすべてを私の利用者名前空間に引き上げさせてもらう提案を別途しようと思います。）
以下、ライブラリでの一括管理に移行させたい関数一覧です。

ライブラリ関数名	スクリプト名	スクリプト内関数名
Wikitext.parseSections	MassProtect	parseSections
	MassDelete	parseSections
Wikitext.parseTemplates	MassProtect	parseTemplates
	MassDelete	parseTemplates
Wikitext.fetch	MassProtect	getLatestRevision
Wikitext.read	MassProtect	read
	MassDelete	read
continuedRequest	MassProtect	getCatMembers getUserContribs getDeletedUserContribs
	MassDelete	getCatMembers
getIcon	MassProtect	getIcon
	MassDelete	getIcon
	MassRevisionDelete	getIcon
	MarkBLocked	images
getLtaList	MassProtect	getLtaList
getVipList	MassProtect	getVipList
massRequest	MassProtect	getProtectionLogs checkPageExistence
	MassDelete	checkPageExistence
	MassRevisionDelete	getParsedComment
	MarkBLocked	markBlockedUsers markIpsInBlockedRanges markLockedUsers markGloballyBlockedIps

--Dragoniez (talk) 2023年11月7日 (火) 10:10 (UTC)

requiresES6というキーワードを使うとガジェットでES6が使えるようです。（phab:rEGAD7793a・phab:T75714） 話を戻すようですが、これを利用して、上記の「JavaScriptとJSDoc」の手法に乗り換えられないでしょうか。古すぎるブラウザで動かないのが難点ですが、ここでいう一括系ガジェット（とくに管理者用のもの）は一部の人だけが使う高度な機能ということで、古いブラウザを無視してしまってもいいのではないでしょうか。en:MediaWiki:Gadgets-definitionだとTwinkleがこれを利用しているようです。--whym（会話） 2023年11月12日 (日) 08:39 (UTC)

なかなか難しいところです。このライブラリ自体はテンプレートパーザーを主としており、これがclass Templateとclass ParsedTemplate extends Templateのクラス継承をしています。ガジェットだけではなくAN Reporterをはじめユーザースクリプトでも使いたいと思っており、ざっと検索するだけで100名以上使用者がいるため、ブラウザ互換の下方修正は避けたいです。 --Dragoniez (talk) 2023年11月13日 (月) 11:20 (UTC)

本来ES5にないクラスを使いたいという目的と、ES5互換性を維持したいという目的とを両立させようとするために、無理が生じているように見えます。互換性については、ES6に限定すると何人の既存ユーザーがガジェットの利用を中止することになるか分かりますか。100人程度のうちでなら該当者（古すぎるブラウザを使っている人、使わざるをえない人）は0でもおかしくないように思いますが。mw:Template:Compatibility browserのGrade Cの中だと、Internet Explorer 11とSafari 9あたりでしょうか。閲覧者の統計によるとIE使用者は最近では0.1%程度で、Safari 9はそれ以下のようです。今後はさらに減っていくだろうと思います。--whym（会話） 2023年11月30日 (木) 12:25 (UTC)

Grade CはそもそもJavaScript features may or may not workとあります。すなわち、MediaWiki側ではGrade CのブラウザでJavaScriptが使えることを保証していません。Grade AのブラウザでES6が使えないものはあるでしょうか。--ネイ（会話） 2023年11月30日 (木) 12:47 (UTC)

取り下げ ご意見ありがとうございました。JavaScriptベース、ES6準拠のコードに、いつになるかは分かりませんがポートしようと思います。MediaWiki名前空間のファイルは上書き使用しますのでそのまま残しておいてください。 --Dragoniez (talk) 2023年12月9日 (土) 11:17 (UTC)