npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

textlint-rule-no-mix-dearu-desumasu

v6.0.3

Published

textlint rule that no mixed である and ですます.

Downloads

143,066

Readme

textlint-rule-no-mix-dearu-desumasu Actions Status: test

敬体(ですます調)と常体(である調)の混在をチェックするtextlintルール。

本文、見出し、箇条書きをそれぞれ独立してチェックし、その中で表記が混在していないかを見つけます。 (本文と見出しの間で表記が混在していても問題ないという意味です)

  • 本文(Markdownなら通常の文章部分)
  • 見出し(Markdownなら#)
  • 箇条書き(Markdownなら* item- item)

Installation

npm install textlint-rule-no-mix-dearu-desumasu

Usage

Via .textlintrc(Recommended)

{
    "rules": {
        "no-mix-dearu-desumasu": true
    }
}

Via CLI

textlint --rule no-mix-dearu-desumasu README.md

Options

それぞれの項目ごとに優先する表記をオプションで設定できます。

  • 本文(Body)
  • 見出し(Header)
  • 箇条書き(List)

デフォルトは ""(空文字)で、多く使われている表記を自動的に優先します。 優先したい表記を "である" または "ですます" で指定します。

{
    "rules": {
        "no-mix-dearu-desumasu": {
             "preferInHeader": "", // "である" or "ですます"
             "preferInBody": "ですます",// "である" or "ですます"
             "preferInList": "である",  // "である" or "ですます"
             // 文末以外でも、敬体(ですます調)と常体(である調)を厳しくチェックするかどうか
             "strict": false
         }
    }
}

この設定は、次のような意味となります。

  • 見出しは自動的に判定(混在のみのチェック)
  • 本文は"ですます"を優先
  • 箇条書きは"である"を優先

その他のOption

  • strict
    • default: false
    • 文末以外でも、敬体(ですます調)と常体(である調)を厳しくチェックするかどうか

たとえば、strict:false(デフォルト)では次のような "であったが" という接続的な"である"は無視されます。 次の例では "であったが" は無視されているため、"です"のみが使われているという判定になります。

OK: 昨日はいい天気であったが、今日は雨です。

strict:falseでは次のような文末が "である""です" といったものだけを検出します。 そのため、次の文章は "です""である" が混在しているのでエラーとなります。

NG: 今日はいい天気である。明日も晴れです。

strict:trueとしていた場合では、以下の文章は "ですが""である" が混在している場合もエラーとなります。 (ですがは接続的、であるは文末)

NG: 今日はいい天気ですが、明日は悪天候である。

Example

詳しくはexample/を動かして試してみてください。

$ textlint --rule no-mix-dearu-desumasu README.md -f pretty-error

no-mix-dearu-desumasu: 本文: "である"調 と "ですます"調 が混在
=> "である" がである調
Total:
である  : 3
ですます: 3

textlint-rule-no-mix-dearu-desumasu/example/README.md:7:7
                    v
    6. 
    7. 結果として「である」調と「ですます」調の使われる数をだしたものである。
    8. 
                    ^

✖ 1 problem (1 error, 0 warnings)

FAQ

Q. 箇条書きの際に「である」調が混在することもあるのでは?

A. 本文、見出し、箇条書き をそれぞれ別々にカウントします。

箇条書き(- リスト)同士の間で混在している場合はエラーとなりますが、 本文箇条書きでの混在は問題ありません。

  • 本文(Markdownなら通常の文章部分)
  • 見出し(Markdownなら#)
  • 箇条書き(Markdownなら* item- item)

それぞれ、別々に扱っているため、これらの間での混在は問題ありません。

Q. なぜデフォルトでは文末のみの検出なのですか?

A. strict: trueは誤検知の可能性があるので、デフォルトの判定を緩くするためです。

textlintでは多くのルールはfalse positiveにならないように、デフォルトを緩く設定しています。 厳しく(接続的な"である"なども)検出したい場合は、{ "strict": true } オプションが利用できます。

Q. 2.0(以前)と同じ挙動にするにはどうすればよいですか?

A. オプションに"strict": trueを追加してください。

2.0

{
    "rules": {
        "no-mix-dearu-desumasu": {
             "preferInHeader": "", // "である" or "ですます"
             "preferInBody": "ですます",// "である" or "ですます"
             "preferInList": "である"    // "である" or "ですます"
        }
    }
}

3.0

{
    "rules": {
        "no-mix-dearu-desumasu": {
             "preferInHeader": "", // "である" or "ですます"
             "preferInBody": "ですます",// "である" or "ですます"
             "preferInList": "である",    // "である" or "ですます"
             // 文末以外でも、敬体(ですます調)と常体(である調)を厳しくチェックするかどうか
             "strict": true
        }
    }
}

関連Issue

Q. これは誤判定なのでは?

A. 以下のIssueに書き込んで下さい。

Further Reading

リファクタリング例

このルールを使ってリファクタリングしてみた例です。

-先ほどのgulpタスクの例では、既にモジュール化された処理を`pipe`で繋げただけであるため、
+先ほどのgulpタスクの例では、既にモジュール化された処理を`pipe`で繋げただけで、
 それぞれの処理がどのように実装されているかはよく分かりませんでした。
-BufferはStringと相互変換が可能であるため、多くのgulpプラグインと呼ばれるものは、`gulpPrefixer`と`prefixBuffer`にあたる部分だけを実装しています。
+BufferはStringと相互変換が可能なので、多くのgulpプラグインと呼ばれるものは、`gulpPrefixer`と`prefixBuffer`にあたる部分だけを実装しています。
-gulpではプラグインが持つ機能は1つ(単機能)であること推奨しています。
+gulpではプラグインが持つ機能は1つ(単機能)とすることを推奨しています。
-`jQuery.fn`の実装を見てみると、実態は`jQuery.prototype`であるため実際にprototype拡張していることがわかります。
+`jQuery.fn`の実装を見てみると、実態は`jQuery.prototype`なので、prototype拡張していることがわかります。
-単純なprototype拡張であると言えるので、利点はJavaScriptのprototypeと同様です。
+単純なprototype拡張なので、利点はJavaScriptのprototypeと同様です。
-まだNode.jsで使われているCommonJSやES6 Modulesといったものがなかった時代に作られた仕組みであるため、
+まだNode.jsで使われているCommonJSやES6 Modulesなどがなかった時代に作られた仕組みなので、

他にいい代替表現など書き方の指摘を募集しています。

敬体(ですます調)、常体(である調)の判定は以下のライブラリを利用しています。

Tests

npm test

Contributing

  1. Fork it!
  2. Create your feature branch: git checkout -b my-new-feature
  3. Commit your changes: git commit -am 'Add some feature'
  4. Push to the branch: git push origin my-new-feature
  5. Submit a pull request :D

License

MIT

Acknowledge

Thanks for RedPen.