モノレポ化を推進し、misskey.jsやmfm.jsなどをmisskey-dev/misskey/packagesに統合する

[tamaina]

Summary

せっかくモノリポ化したのだから次に挙げるようなリポジトリをこちらに統一すれば効率良い開発ができそう

（しゅいろ曰く「モノレポ風」なので厳密にモノレポではないかもしれない）

モノレポにしてもnpmへのライブラリ類の配布は継続されます。モノレポにすると、Misskeyのリリースと同時にライブラリが更新されたり、Misskey本体へのプルリクエストと一緒にライブラリの変更が付属したりするので、よりライブラリが本体の仕様に追従するようになるでしょう。

Suggesting Packages

1. mfm.js

mfmの仕様はMisskeyの仕様上重要なものであるにも関わらず、別リポジトリになっているが故にIssueや作業内容が分散し把握しにくくなっているので、リポジトリを統合したほうがよさそう

2. misskey.js

• APIを編集するときに同時に内容を変更できる
• Misskey Webと型が整合するのがmisskey,jsのリリースを待たなくてよくなる

3. assets

misskey.jsとかmfm.jsを統合するならassetsも統合するのが妥当そう

4. summaly

misskey.jsとかmfm.jsを統合するならsummalyも統合するのが自然だが、summalyはMisskeyの使用に限定してないので微妙ではある
私の認識のsummalyの立ち位置はcafy(完全にMisskey外でも使える)とmisskey.jsの間ぐらい

5. misskey-hub

Pros

• 機能追加・変更と同時にドキュメントの編集・追加を行うことが簡単になったり意識づけられたりするので、ドキュメントが充実してくると思う
• Crowdinにmisskey-hubの内容を追加することで翻訳の参加が増えるかもしれない

Cons

• ドキュメントの変更ごとにコミットやPRが発生するので、どうしても本体開発よりコミット割合が多くなる
• 文章や画像が増えるのでリポジトリの容量が増える
  • npm installは任意でいいのでそこらへんの容量は大丈夫そう
• GitHub Pagesを使おうとするとビルドでもコミットが増える（netlifyを使っちゃえば解決する）

6. xev

xevくんに対して現役のパッケージであることの自覚を持たせる (joke)

[marihachi]

将来的にMFMパーサが言語ごとに用意されることが考えられるし、
MFMの仕様を他のリポジトリ(Misskeyなど)に移す方が理想的だろうなとは思ってる。
(MFMの実装がmfm.jsだけとも限らない)

ただ、パーサの実装方法によっては全ての仕様を技術的に実現できる・できないがあるかなと思うから、
パーサの実装毎でサポートする仕様は限定されてくると思う。
この辺を実装毎で本来の仕様とどう違うについて説明するか、実装ごとで別々の仕様を定めておくことが必要そう。
めんどくさいかも。

(mfm.js)実装の仕様 + (misskeyリポジトリ)MFMの仕様
が良いのかな

[marihachi]

mfm.jsはサードパーティでも使えるようにパッケージとしてnpmに公開する必要はある
その辺どうなるんだろう

misskey.jsも同じ

[marihachi]

mfm.js、misskey.jsは言語ごとに実装が増えていくだろうから、
misskeyに入れるのは賛成できないかも。

たとえば、仮にRustやPythonのmisskey.jsの移植実装が追加されるとなったら、
misskeyリポジトリに追加されるのだろうか？
別リポジトリとして追加されるなら、再度分離されることになると思う。

[tamaina]

たとえば、仮にRustやPythonのmisskey.js(/mfm.js)の移植実装が追加されるとなったら、
misskeyリポジトリに追加されるのだろうか？

Misskeyがその時にRustやPythonを採用しているのであれば追加していいと思う(その場合はモノリポ自体適当でなくなっている気がするけど)

Misskeyで使っていてMisskeyの仕様と密接に関わっているからモノリポに含めることで利益が生まれる、Misskeyで使っていないもののことは当然考えない

Misskeyで使っていない実装はメンテ頻度も自然に下がってしまうだろうし

他言語の他の実装を作っても手に負えなくなるだけだと思うので考えないほうがいいと思う

[tamaina]

mfm.jsはサードパーティでも使えるようにパッケージとしてnpmに公開する必要はある

その辺どうなるんだろう

misskey.jsも同じ

今まで通り公開する(なんでこんな疑問を持たれてしまったのだろうか…

[marihachi]

たとえば、仮にRustやPythonのmisskey.js(/mfm.js)の移植実装が追加されるとなったら、
misskeyリポジトリに追加されるのだろうか？

Misskeyがその時にRustやPythonを採用しているのであれば追加していいと思う(その場合はモノリポ自体適当でなくなっている気がするけど)

そもそもの話を言い忘れてた、申し訳ない。
「サードパーティ向けのライブラリを他の言語向けにも作るかも」的なことを @syuilo が言ってた気がして、
まだ気が変わってなければ、その方向からは外れてしまう気がする。

[rinsuki]

ライセンスが別々なものを1リポジトリに入れると GitHub の LICENSE が See LICENSE file になってちょっとアレ

[rinsuki]

って思ったけど今でもちゃんと出てなかった (何でだ？)

[Johann150]

Crowdinにmisskey-hubの内容を追加することで翻訳の参加が増えるかもしれない

I would see this as a disavantage (con) because there were problems with the Markdown documents in Crowdin. As far as I know this was the reason why it was moved into a separate repository.

[tamaina]

Ethereumのドキュメントを触ったときはあんまり不便さを感じなかった、UXは微妙だったけど
（もしかして承認フローに問題があるのかしら？）

あと、翻訳プラットフォームがCrowdinである必要はない気がする

[syuilo]

私的にはこのリポジトリは「Misskey本体」のリポジトリに保ちたいんだよね
Misskey本体以外を含めるとビルド周りがちょっと複雑になりそう

misskey.js、mfm.jsは入れても良いような気はするけど、それ以外は微妙

論点

1. このリポジトリの位置付けを「Misskey本体」にするのか「Misskey全体」にするのか
2. ↑で前者とした場合、misskey.jsやmfm.jsを含めるか

[ThatOneCalculator]

1. このリポジトリの位置付けを「Misskey本体」にするのか「Misskey全体」にするのか

2. ↑で前者とした場合、misskey.jsやmfm.jsを含めるか

後者 (翻訳機を使っているのですが、理解は正しいでしょうか？)

[marihachi]

(1)については「Misskey本体」派かも
「Misskey全体」をリポジトリの対象にした場合は、コミットの内容がMisskeyについてのものとMisskey関連のものが混在することになるはず。
例えばmisskey.jsのバージョンを指定してソースコードを見たい時はどうなるんだろう...
複雑になりそうな雰囲気はある → (2)については含めない派

[tamaina]

misskey.jsやmfm.jsのリリースは本体と同じタイミング・バージョンにした方がいいと感じた
(Misskey本体の方が明らかに更新頻度多いけど)

[marihachi]

MFMの仕様に関しては別でissueを立てました。

• MFMの仕様書を移動する #8267

[syuilo]

このリポジトリをMisskey本体ではなくてMisskey全体とした方が開発効率の観点からは優れているからそのようにしようかな
misskey-hub、misskey-js、mfm-jsは含めて良さそう

[4ioskd]

このリポジトリはMisskey本体とした方が良いように思います。

そしてmfm.jsやmisskey.jsはMisskeyの象徴的なプログラムの一部であり、かつSummalyやAiScriptなどの他のプログラムも含めると、Misskeyは高度に複雑なネットワークサーバーソフトウェアと言えるかと思います（ゆえにMisskey独自の様々な機能が光るのですが）。このため、私のような非コードコントリビューターはもちろん、ベテランではないコードコントリビューターにとってはどのプラグラムがMisskeyのどの部分で動いているのか分かり辛いところがあるように思います。特にベテランではないコードコントリビューターにとってはMisskeyの全てを理解するのに時間がかかるでしょうし、そういったコントリビューターが効率よく適切にコントリビュートするための環境としては、現状の様にmfm.jsやmisskey.jsなどが別リポジトリとして存在することが良いかと思います。また、しゅいろ氏のリポジトリにあるSummalyやAiScriptなども、misskey-dev下にそれぞれリポジトリとして存在するとより分かりやすいと言えます。（そういう意味ではMisskeyというソフトウェアとその上で走っているプログラムをスムーズに理解するための技術的ドキュメントが欲しい、とか思ってたりします）。

何より、過去にmisskeyからmfm.jsやmisskey.js等を別リポジトリに切り離す決断を行った以上、それを元に戻してもう一度多くの国内・海外のコントリビューターや開発者に周知させるには、misskeyが属するfediverseは投稿の拡散性が無い故に限界があり、多くのユーザーに浸透するには時間がかかるかと考えます。
そもそも、別リポジトリにあるプログラムはサードパーティー向けにnpmとして配布していたり、異なったライセンスが付与されていてもう一度このリポジトリに組み込む際にどのようにして整合性を保つか、などなど...結果的に検討や作業に時間がかかるタスクを新たに生み出してしまうように思います。ちなみに、他のfediソフトウェアのリポジトリではメインのソフトウェア上で走るプラグラムやドキュメントや特殊なプログラム（DockerやAnsible対応など）はfediソフトウェアとは別のリポジトリで管理される傾向にあります。

misskey-hubについては、これは公式サイトであり主にユーザー向けのドキュメントサイトでもありますから、Misskeyというソフトウェアとは別個のリポジトリであるべきでしょう。

ちなみに、assetsについてはこのリポジトリに組み込んで問題ないかと思います。

[marihachi]

開発されているプログラムの一部分を別リポジトリにコピーして、サードパーティ向けに配布するってやり方もたまに見る。
そういうのはどうだろう

misskey-hubをMisskeyリポジトリに置くのは違う気がする

[4ioskd]

開発されているプログラムの一部分を別リポジトリにコピーして、サードパーティ向けに配布するってやり方もたまに見る。そういうのはどうだろう

アリだと思う。

misskeyというソフトウェアを開発する過程から生まれたプログラムとして、mfm.jsやmisskey.jsをサードパーティーに配布する。そして、それらを利用したソフトウェアやプログラムの開発をmisskey関係やそれ以外の領域での開発で利用してもらう。ただし、それらをちゃんと管理・開発するには現状のままではしゅいろ氏が3人ぐらい必要なので、それらの管理・開発に興味があるコントリビューターのさらなる貢献は必須。例えば、共同管理制にするなど。

配布する理由は3つ。
1.脱中央集権ソーシャルネットワークとしてのmisskeyを中心に『（仮）misskeyネットワーク』を形成するため（『データ経済圏』『エコシステム』などのワードが浮かぶが、良い言葉が思いつかない）
2.プログラムを第三者によって利活用されることを通して、misskeyの存在を知るきっかけを増やす、プログラム自体のブラッシュアップやその可能性を広げる
3.しゅいろ氏のプログラムは、それぞれが単独のプログラムとして十分な評価を受けていないし、もっと評価されるべき

[tamaina]

@4ioskd の理念には共感するし、このIssueはライブラリの公開を停止するとかそういう前提を覆すものではない（というのは先頭に追記しておいた）。
あくまで**「開発効率の面で同じgitリポジトリにするかどうか」**という話。

各ライブラリの結合を密にする（モノレポにする）か疎にする（別リポジトリのままにする）かはリーダーであるしゅいろの意思によるところが大きそう

assetsが別リポジトリであるのは、ライセンスをAGPLにしたくなかったのでそうしたのだと思う

[syuilo]

前言った通りmisskey-hub、misskey-js、mfm-js辺りを含めたくなってきたけど、GitHubと連携してなんやかんやするサードパーティのサービス(codecovとかokteto)は、モノリポ構成に対応してないんじゃないかと思った(詳しくは調べてない)
そこらへんがややこしくなりそう

[tamaina]

codecov?
https://docs.codecov.com/docs/flags

oktetoのモノリポ対応ってどんな感じなんだろう

[marihachi]

感覚的には、モノレポにして色んなものを1つのリポジトリに入れて上手くいくビジョンが見えない
自分だったらやらないと思う

そもそもGitやGitHubが1つのソフトウェアのバージョン管理をするために設計されていて、そこに複数のソフトウェアを集約しようとするんだからね。それなりの工夫や試行錯誤が必要になる。

[tamaina]

モノリポにするかどうかというのは、Misskeyとその周辺ライブラリ・ドキュメントを、1つのソフトウェアとして扱うか別々のソフトウェアとして扱うかの話だと私は思っている。

私は1つのソフトウェアにしたほうが上手く行くのではないかと思っている。

[marihachi]

1つのソフトウェアにしてサードパーティ開発者にどれくらい受け入れられるかってところも疑問

[tamaina]

モノリポにすればライブラリとMisskey本体の変更が同期的に行われるようになることが期待されるので、サードパーティ開発者にとってメリットしかないと思っている

[4ioskd]

ちなみに私の意見はここで述べた内容から基本的には変わってない #8168 (comment)

codecovとoketoについては詳しく調べていただくとして、、私としてはしゅいろ氏のこの意見に賛成する #8168 (comment)

[tamaina]

#8168 (comment)

文章読むの苦手なので段落をこれの半分か3つぐらいに分割してほしい

[syuilo]

このリポジトリに集約したいモチベーションとしては、

モノリポにすればライブラリとMisskey本体の変更が同期的に行われるようになることが期待されるので、サードパーティ開発者にとってメリットしかないと思っている

↑に加えて、Misskey Hubにリリースノート追記するコミットを実際の変更のコミットと一緒に行える点

[syuilo]

oktetoのモノリポ対応ってどんな感じなんだろう

misskey hubへの変更だったらmisskey hubが、本体の変更だったら本体が立ち上がってくれたら良いなと思ったけど難しそう
まあどっちも立ち上がるようにしても良さそう

[tamaina]

（リリースノートとドキュメントはMisskey本体で提供するべきじゃないかなぁと思っている）
（Misskey Hubは大まかな機能紹介とかに留めてモノリポに含まない→ドキュメント詳細はそれぞれのインスタンスのドキュメントに飛ばす（ユーザーに予めインスタンスURLを入力させておく））

[4ioskd]

リリースノートについての私の考えは先ほど閉じたプルリクに書きました。 #8637 (comment)
ドキュメントはMisskey Hubに集約させた方が良いと考える。各インスタンスにドキュメントやその詳細を置いておくと、例えばmisskey.io/api-docやmisskey.io/mfm-cheat-seatのように一部のドキュメントへのアクセスが特定のインスタンスに集中したり、またドキュメントやその詳細が各インスタンスにひっついてくるとそれぞれのドキュメントへのissueやPRをどこに出せば良いのか、ということになる(misskey-dev/misskeyに出されても困るし）。

[rinsuki]

まあでも /api-doc や /mfm-cheat-seat はインスタンスのバージョン/独自実装依存なのでインスタンス側にあってもいいんじゃないって気はするけど (自分のいるところを見られるようにするといいねというのはそう; これはこのサーバー固有の情報ですよって警告でも出す？)

[tamaina]

may be related to #4128

[tamaina]

しゅいろはsummalyを含めたくないらしい(?)けどsummalyこそ含めるべきだと思う

[4ioskd]

賛成！
（以下、私の意見より引用）

＞また、しゅいろ氏のリポジトリにあるSummalyやAiScriptなども、misskey-dev下にそれぞれリポジトリとして存在するとより分かりやすいと言えます。（そういう意味ではMisskeyというソフトウェアとその上で走っているプログラムをスムーズに理解するための技術的ドキュメントが欲しい、とか思ってたりします）。
#8168 (comment)