textlint-rule-prhの使い方覚書です。
textlintの使い方まとめ記事はこちらです。
目次
表記揺れの自動修正(textlint-rule-prh)
vscode→ VS Code のような表記の統一をするために、表記揺れの自動修正するものがあります。
textlint-rule-prh、textlint-rule-proofdictなど、調べたらいろいろとでてきましたけど、textlint-rule-prhが圧倒的にダウンロード数と情報量が多かったです。こちらを使いました。
なお、うっかりと入れてしまいましたが、textlint-rule-spellcheck-tech-wordは移転しているようでいりませんでした。
いずれもazuさんが開発者のようです。
npm install textlint-rule-prh --save-devルール(techbooster.ymlやWEB+DB_PRESS.yml)
例によってルールは自分でも作れるようです。けれど技術書はさほど変わらないでしょうと、ありものを使います。楽させてもらいます。
techbooster.yml
WEB+DB_PRESS.yml
が.textlintrcに追記すればOKです。ルールの中に書きます。
"rules": {
"preset-ja-technical-writing": true,
"ja-technical-writing/ja-no-mixed-period": false,
"ja-technical-writing/no-exclamation-question-mark": false,
"prh": {
"rulePaths": [
"node_modules/prh/prh-rules/media/WEB+DB_PRESS.yml",
"node_modules/prh/prh-rules/media/techbooster.yml"
]
}
}修正箇所が多いと若干表示に時間がかかるようですが、無事表示されるようになりました。
techbooster.ymlやWEB+DB_PRESS.ymlの場所
\node_modules\prh\prh-rules\media複数のルールは無限ループにハマる!?(WEB+DB_PRESS.ymlとtechbooster.ymlのコンフリクト!?)
WEB+DB_PRESS.ymlとtechbooster.ymlのルールって両方を使うと一部、対立しているんですよね。
だから修正後、再度修正するとまた元に戻るという無限ループにハマったことがありました。片方が修正されると別のルールにひっかかって再度修正されてしまうようです。
たとえば、
# - expected: ユーザー$1
# pattern: /ユーザ([^ー])/
- expected: ユーザビリティ
pattern: /ユーザービリティ/他にもありましたが、WEB+DB_PRESS.ymlを直下きして対応しました。正規表現が使えるようですが、手っ取り早くバッティングしているところをコメントアウトする方法もあります。
また、WEB+DB_PRESS.ymlとtechbooster.ymlのルールもバッティングしているようです。
漢字よりひらがながいいよ。ひらがなより漢字がいいよ…の無限ルールにはまりました。
個人的には優しいひらがな派なので、ひらがな優先したいですね。漢字が多めのtechbooster.ymlをコメントアウト。
# - expected: 他の
# pattern: ほかの
# prh: ひらがなで書かず、漢字で書くと読みやすくなります
# - expected: 分かる
# pattern: わかる
# prh: ひらがなで書かず、漢字で書くと読みやすくなります #- pattern: /わかれ([^ば])/
# expected: 分かれ$1
#- pattern: /わけ([らるれろてよ、])/
# expected: 分け$1言えもかぶり症状発生。かなを優先。
# - pattern: いえない
# expected: 言えない
# - pattern: いえなく
# expected: 言えなく
# - pattern: いえる
# expected: 言える
# - pattern: いわれる
# expected: 言われるほんの一部、漢字を優先させたところもあります。
# - expected: もっとも
# pattern: 最も
# prh: ひらがなで書かず、漢字で書くと読みやすくなります# - pattern: 仕方
# expected: しかたどちらかというと、
node_modules/prh/prh-rules/media/WEB+DB_PRESS.ymlを優先して使っています。
ルールがバッティングしたときは個別対応で上書きしたらうまくいきますかね。
textlintで特定の行を無視する(textlint-filter-rule-comments)
ここだけ修正したくないとか、たまにあります。作者さんの記事がありましたのでこれで対応!
<!-- textlint-disable prh -->
ターミナルコマンドはgitとうちます。
<!-- textlint-enable prh -->npm install textlint-filter-rule-comments{
"filters": {
"comments": true
}
}textlintで`<!– textlint-disable –>`などのコメントで一部だけルールを無効化する方法とフィルタールールについて “textlintで特定のルールのエラーを無視する – Qiita” https://t.co/nhJ0N62f7C
— azu (@azu_re) November 23, 2017
prh.ymlの独自ファイル修正
独自のルール修正ファイルを作る場合は、prh.ymlというファイルを作成します。
version: 1
rules:
- expected: CodePen
pattern:
- Codepen
- codepenCodePenという文字を修正する設定です。サービス名や会社名を登録することが多いです。
そののちに、.textlintrcにprh.ymlを追加します。
"rules": {
"preset-ja-technical-writing": true,
"ja-technical-writing/ja-no-mixed-period": false,
"ja-technical-writing/no-exclamation-question-mark": false,
"prh": {
"rulePaths": [
"./prh.yml"
]
}
}prh.ymlの指定がおかしい場合、ターミナルにエラーがでます。大抵、パス間違えなどの凡ミスですかね。ただ、タブのoutputにでるため、注意ください。
公式リファレンスはこちらのようです。
表記修正の悩みどころ
一部注意した方がよいものもあります。
いい => よい textlint通常、よいに修正する気がします。けどSNSの「いいね」が「よいね」になってしまう。それ以外にも「お使いいただけます」が「お使よいただけます」に😓
ひとまずこれで様子見。
# - pattern: いい
# expected: よい
- pattern: /いい([で])/
expected: よい$1アプリ => アプリケーションアプリはもう一般的によく使うため、アプリでもいい気がします。
# - expected: て
# pattern: /(当)?てて/
# regexpMustEmpty: $1たとえば、「切り捨ててしまう」のような文章でもひっかり、「切り捨てしまう」に直します。いったんコメントアウトで回避。
ダブルクォーテーションという方が多いのでコメントアウト(Google調べ)。
# - expected: クオート
# pattern: /クォート|クオーテーション|クォーテーション/「見つけたら…」は漢字にされたくないですね。
# - pattern: つけた
# expected: 付け足一文に二回以上利用されている助詞 “も” が見つかりました。
一文に二回以上利用されている助詞 "も" が見つかりました。癖なのでしょうが、このエラーが出ることが多いです。。
(例)登録しても登録しなくてもOKです。
てもの重複ですね。個人的にこのぐらい許容してもいいのですが、textlintの方を修正するのが面倒なので次のようにしたらエラーが消えました。
(修正案)登録するか否かはどちらでもOKです。
コメント