azu

使う側のbundlerの設定をすれば、今のtextlint-rule-prhをブラウザで動かせることを知っています。 https://github.com/textlint/editor などでやっています。 fsの設定をするのとpathの設定をするのは、大した違いはないんじゃないかなという話をしたかったです。 (使うshimが異なるというのはありますが)

今の修正方針で動くのはわかるのですが、そこまで textlint-rule-prh で頑張るべきなのか という疑問があります。 どちらかというと prh 側でPureなJavaScriptとして動作するものをexportする形に修正して、textlint-rule-prh を修正という流れでやらないと、対症療法的になるのではないかという懸念があります。 たとえば、@textlint/kernel はPureなJavaScriptとして動作させるためにモジュールを分けています。(そのために、typesを分けるとかモジュールをかなり意識して作っています) ブラウザで動かすという目的をハックに近い形でやると不意に壊れる可能性が高いので、prhをラップしてるtextlint-rule-prh側でどこまでカバーするべきなのかという不安があります。

ブラウザで動かすという目的だけに絞るなら、fsとかpathをdead code eliminationで完全に消し切った textlint-rule-prh のbundleを提供にしないと、今の構造だと安定したものは提供できないと思います (内部的なライブラリの重複とかは発生してしまうけど) 利用者側でfsだけをshim当てて、pathだけはtextlint-rule-prh側で解決するだとなんか中途半端という印象です。 もしくは、利用者側で責任を持って全部shimを当ててもらえるようにドキュメントを用意するとかになると思います。

prhのユーザーは、textlint-rule-prhとprhのCLIがほとんどだと思っています。 なのでモジュールのBREAKING CHANGEはそこまで大きな影響なくできる可能性はありそうです。 prhを修正して、fsをEnginesから取り除いてPure JSとして使えるインターフェースを用意するのはできそうかなーという感覚はあります - https://github.com/prh/prh/blob/602794323a717b9511ea23e32c5b1e760cf16227/lib/engine.ts#L115-L121 たぶんこのメソッドだけどうにかすれば、Enginesをexportして使えるようにすればいいはず prhのメンテナの vvakame さんに相談して、メンテナンス権限をもらってやるのが、prhユーザーにとっても良い気はしますね。ちょっと後で issue を立てて聞いてみます。 prh自体でやりたいことは - ブラウザ対応のためにEnginesを綺麗にしたい(機能的な違いは出ない) - fs依存を別ファイルにするぐらいのイメージ - 依存が古いのでアップデートしたい - CLIのインターフェースは変わらないはずなので、挙動は特に変えない方針 - [`exports`](https://nodejs.org/api/packages.html#main-entry-point-export)を使うとかTSのアップデートはするのでBREAKING CHANGEとしてmajorアップデートの予定 - ただし、実際影響受けるのはtextlint-rule-prhだと思うので、それはこちらで吸収する という方針ですかね。

- https://github.com/prh/prh/issues/50 Issueを作りました