Breaking Change: 文体が統一されていてもpreferIn設定に違反する場合エラーとなるように変更

[yo1000]

現行では、"ですます" に統一しなければならない、といった文書の表現規則を事前に設けることができません。
あくまで記述された文章の結果表現が、"ですます"、ないし "である" に統一されていることだけが検査されます。

執筆前に、これから記述する文書は "ですます" に統一しなければならない、といった規則を設けたい場合があります。

こういった事前定義規則への違反を検知できるようにするため、デフォルトの動作を変更しました。
変更後は、preferIn の設定に従わない場合についても、等しくエラーとなります。

こういった事前定義規則への違反を検知できるようにするためオプションを追加しました。
オプションを使用すると、preferIn に設定された表現と一致しない場合に、エラーとなります。

{
    "rules": {
        "no-mix-dearu-desumasu": {
             "preferInHeader": "", // "である" or "ですます"
             "preferInBody": "ですます",// "である" or "ですます"
             "preferInList": "である",    // "である" or "ですます"
             // 文末以外でも、敬体(ですます調)と常体(である調)を厳しくチェックするかどうか
             "strict": false,
             // preferInでの設定を、"優先" ではなく、"強制" するかどうか
             // 有効化した場合、被検査テキストの表現が統一されていても、
             // preferInオプションで指定された表現に強制する
             "enforcePreferences": false
         }
    }
}

---

例えば、次の設定を事前に用意していたとします。

{
    "rules": {
        "no-mix-dearu-desumasu": {
             "preferInBody": "ですます",// "である" or "ですます"
             // preferInでの設定を、"優先" ではなく、"強制" するかどうか
             // 有効化した場合、被検査テキストの表現が統一されていても、
             // preferInオプションで指定された表現に強制する
             "enforcePreferences": true
         }
    }
}

従来であれば、"preferInBody": "ですます" が設定されていても、以下の文章はエラーにはなりません。

今日はいい天気である。気持ちの良い朝である。

しかし、事前定義規則により、文章表現を "ですます" に強制したい場合があります。
今回追加したオプションを使用して、"enforcePreferences": true が設定されていると、この文章はエラーになります。

以下の表現に改めれば、エラーは解消されます。

今日はいい天気ですね。気持ちの良い朝です。

[azu]

ありがとうございます。

preferの考慮漏れのような気もするので、新しいオプションなしにprefer*が指定されている場合は強制して良いような気もします。
混在させないという設定は""(空)の指定で実現できてるはずなので、"preferInBody": "ですます" とかを指定した時点で"である"を使ったらエラーにするのは違和感がない気はしています。

そのため、特に今の挙動(混在はしてないけど、preferじゃない書き方が入ってるケースをスルーする)のユースケースが思いつかなければ、今の挙動をenforceの挙動に変えてしまって問題ないと思います。

丁寧にやるならオプションを追加するのが正しそうですが、デフォルトを強制にした場合、ほとんど使われないオプションな気はするのでオプションはなしで良いかなと思いました。(破壊的な変更なので、major updateでリリースする形です)

minor updateで入れたい場合は、今のオプションありで入れて、次のmajorでデフォルトの挙動を変更する感じになりそうですね。

どちらか良いと思いますか?

[azu]

📝 オプションありのままで行く場合のコメント

if (this.options.isEnforcePreferences) { 
  return ...
}

return ...

三項演算子にまとめる必要があまりなさそう(ロジック的に異なるものなのでブロック的にわかれてた方が、後から片方を消しやすい)なので、ifで分けてearly returnした方が良さそう。

[yo1000]

@azu
レビューありがとうございます。

丁寧にやるならオプションを追加するのが正しそうですが、デフォルトを強制にした場合、ほとんど使われないオプションな気はするのでオプションはなしで良いかなと思いました。(破壊的な変更なので、major updateでリリースする形です)

minor updateで入れたい場合は、今のオプションありで入れて、次のmajorでデフォルトの挙動を変更する感じになりそうですね。

どちらか良いと思いますか?

Major updateで、破壊的変更として取り込むか、Minor updateで、段階的に取り込むかですが、リリースにかかる期間にどの程度影響を与えるか次第で選択できればと考えています。

いずれを選択した場合も、さほど時間を空けずにリリースされるのであれば、Majorでデフォルト挙動自体を変更してしまう形が好ましく、次期Major updateに他にも何らかの機能追加等が計画されており、少し間を空けるようであればMinorを経由する形が良いです。

リリース時期に関する何らかの計画等はあるでしょうか。選択されたリリース方法に応じた内容で修正を加えようと思います。

[azu]

このルール自体は、マージしたらすぐリリースしてしまうと思います。

presetの方は半年に1度にしていて、次回は1月リリースの予定です。
https://github.com/textlint-ja/textlint-rule-preset-japanese
https://github.com/textlint-ja/textlint-rule-preset-ja-technical-writing

[yo1000]

@azu
ご回答ありがとうございます。

それでは取り急ぎ、Major updateでリリース可能となるよう修正を加えようと思います。

[azu]

ありがとうございます

[azu]

https://github.com/textlint-ja/textlint-rule-no-mix-dearu-desumasu/releases/tag/v6.0.0
リリースしました

[azu]

presetのリリースPR(1月にマージの予定)

• Version Packages textlint-rule-preset-japanese#119
• Version Packages textlint-rule-preset-ja-technical-writing#142

Canary版:

$ npm install textlint-rule-preset-japanese@next
$ npm install textlint-rule-preset-ja-technical-writing@next