Skip to content

Commit 20ef468

Browse files
authored
chore: update deps (#126)
1 parent fca4ca2 commit 20ef468

File tree

6 files changed

+23
-22
lines changed

6 files changed

+23
-22
lines changed

Diff for: ja/ESLint/README.md

+4-4
Original file line numberDiff line numberDiff line change
@@ -123,7 +123,7 @@ debug("Hello");
123123
- [Documentation - ESLint - Pluggable JavaScript linter](http://eslint.org/docs/developer-guide/working-with-rules "Documentation - ESLint - Pluggable JavaScript linter")
124124
- [コードのバグはコードで見つけよう!|サイバーエージェント 公式エンジニアブログ](http://ameblo.jp/principia-ca/entry-11837554210.html "コードのバグはコードで見つけよう!|サイバーエージェント 公式エンジニアブログ")
125125

126-
## どういう仕組み?
126+
## どのような仕組み?
127127

128128
ESLintはコードをパースしてASTにして、そのASTをJavaScriptで書いたルールを使いチェックする
129129
という大まかな仕組みは分かりました。
@@ -184,7 +184,7 @@ function lint(code){
184184
```
185185

186186
Pub/Subパターンを上手く使うことで、ASTを走査するのが一度のみで、
187-
それぞれのルールに対してどういうコードかという情報が`emit`で通知できていることがわかります。
187+
それぞれのルールに対してどのようなコードかという情報が`emit`で通知できていることがわかります。
188188

189189
もう少し具体的にするため、実装して動かせるようなものを作ってこの仕組みについて見ていきます。
190190

@@ -240,7 +240,7 @@ add(1, 3);
240240

241241
このようにして、ルールは `context` という与えられたものだけを使うので、ルールがMyLinter本体の実装の詳細を知らなくても良くなります。
242242

243-
## どういう用途に向いている?
243+
## どのような用途に向いている?
244244

245245
このプラグインアーキテクチャはPub/Subパターンを上手く使い、
246246
ESLintのように与えられたコードを読み取ってチェックするような使い方に向いています。
@@ -250,7 +250,7 @@ ESLintのように与えられたコードを読み取ってチェックする
250250
また、ルールは `context` という与えられたものだけを使うようになっているため、ルールと本体が密結合にはなりにくいです。
251251
そのため`context`に何を与えるかを決めることで、ルールが行える範囲を制御しやすいといえます。
252252

253-
## どういう用途に向いていない?
253+
## どのような用途に向いていない?
254254

255255
逆に与えられたコード(AST)を書き換える場合には、
256256
ルールを同時に処理を行うためルール間で競合するような変更がある場合に破綻してしまいます。

Diff for: ja/Redux/README.md

+2-2
Original file line numberDiff line numberDiff line change
@@ -68,7 +68,7 @@ Reduxでは第三者が拡張できる仕組みを _middleware_ と呼んでい
6868
- [Middleware | Redux](http://redux.js.org/docs/advanced/Middleware.html "Middleware | Redux")
6969

7070
どのような拡張を _middleware_ で書けるのか、実際の例を見てみます。
71-
次の _middleware_ はStoreがdispatchしたActionと、その前後でStateにどういう変更があったのかを出力するロガーです
71+
次の _middleware_ はStoreがdispatchしたActionと、その前後でStateにどのような変更があったのかを出力するロガーです
7272

7373
[import, logger.js](../../src/Redux/logger.js)
7474

@@ -143,7 +143,7 @@ const middleware = (store) => {
143143
Reduxの _middleware_ の仕組みは単純ですが、見慣れないデザインなので複雑に見えます。
144144
実際に同じ仕組みを実装しながら、Reduxの _middleware_ について学んでいきましょう。
145145

146-
## どういう仕組み?
146+
## どのような仕組み?
147147

148148
_middleware_`dispatch`をラップする処理ですが、そもそも`dispatch`とはどういうことをしているのでしょうか?
149149

Diff for: ja/connect/README.md

+3-3
Original file line numberDiff line numberDiff line change
@@ -50,7 +50,7 @@ Echoサーバでは `req.pipe(res);` という形でリクエストをそのま
5050

5151
> **Note** _middleware_ となる関数の引数が4つであると、それはエラーハンドリングの _middleware_ とするという、Connect独自のルールがあります。
5252
53-
## どういう仕組み?
53+
## どのような仕組み?
5454

5555
Connectの _middleware_ がどのような仕組みで動いているのかを見ていきます。
5656

@@ -130,7 +130,7 @@ Junctionは、`use(middleware)` と `process(value, (error, result) => { });`を
130130
[import junction-example.js](../../src/connect/junction-example.js)
131131

132132

133-
## どういう用途に向いている?
133+
## どのような用途に向いている?
134134

135135
ConnectやJunctionの実装を見てみると分かりますが、このアーキテクチャでは機能の詳細を _middleware_ で実装できます。
136136
そのため、本体の実装は _middleware_ に提供するインタフェースの決定、エラーハンドリングの手段を提供するだけでとても小さいものとなっています。
@@ -150,7 +150,7 @@ app.use("/foo", function fooMiddleware(req, res, next) {
150150
そのため、ConnectやRackなどのHTTPサーバでは「リクエストに対してレスポンスを返す」というのが決まっているので、
151151
このアーキテクチャは適しています。
152152

153-
## どういう用途に向いていない?
153+
## どのような用途に向いていない?
154154

155155
このアーキテクチャでは機能の詳細が _middleware_ で実装できます。
156156
しかし、多くの機能を _middleware_ で実装していくと、 _middleware_ 間に依存関係を作ってしまうことがあります。

Diff for: ja/gulp/README.md

+3-3
Original file line numberDiff line numberDiff line change
@@ -46,7 +46,7 @@ gulp.task("sass", function() {
4646
- [現場で使えるgulp入門 - gulpとは何か | CodeGrid](https://app.codegrid.net/entry/gulp-1)
4747
- [gulp入門 (全12回) - プログラミングならドットインストール](http://dotinstall.com/lessons/basic_gulp)
4848

49-
## どういう仕組み?
49+
## どのような仕組み?
5050

5151
実際にgulpプラグインを書きながら、どのような仕組みで処理同士が連携を取り動作しているのかを見ていきましょう。
5252

@@ -242,7 +242,7 @@ Node.js Streamのデフォルトでは流れるデータが`Buffer`となり、
242242
このようにして、gulpはタスクに必要な単機能のプラグインを既存のライブラリで作りやすくしています。
243243
これにより再利用できるプラグインが多くできることでエコシステムを構築しているといえます。
244244

245-
## どういう用途に向いている?
245+
## どのような用途に向いている?
246246

247247
gulp自体はデータの流れを管理するだけで、タスクを実現するためにはプラグインが重要になります。
248248
タスクにはさまざまな処理が想定されるため、必要になるプラグインも種類がさまざまなものとなります。
@@ -260,7 +260,7 @@ gulpでは[vinyl](https://github.com/gulpjs/vinyl "vinyl")オブジェクトを
260260
- 既存のライブラリをプラグイン化しやすい
261261
- 必要なプラグインがない場合も、設定としてコードを書くことで対応できる
262262

263-
## どういう用途に向いていない?
263+
## どのような用途に向いていない?
264264

265265
プラグインを複数組み合わせ扱うものに共通することですが、プラグインの組み合わせ問題はgulpでも発生します。
266266

Diff for: ja/jQuery/README.md

+4-4
Original file line numberDiff line numberDiff line change
@@ -15,7 +15,7 @@ jQueryでは`$.fn`を拡張することで、`$()`の返り値となるjQueryオ
1515
<script src="greenify.js"></script>
1616
```
1717

18-
## どういう仕組み?
18+
## どのような仕組み?
1919

2020
このjQueryプラグインがどのような仕組みで動いているのかを見てみましょう。
2121

@@ -39,14 +39,14 @@ $(document.body); // 返り値はjQueryのインスタンス
3939

4040
つまり、jQueryプラグインはJavaScriptのprototypeをそのまま利用しているだけに過ぎないということがわかります。
4141

42-
## どういう用途に向いている?
42+
## どのような用途に向いている?
4343

44-
jQueryプラグインの仕組みがわかったのでどういう用途に有効な仕組みなのか考えてみましょう
44+
jQueryプラグインの仕組みがわかったのでどのような用途に有効な仕組みなのか考えてみましょう
4545

4646
単純なprototype拡張なので、利点はJavaScriptのprototypeと同様です。
4747
動的にメソッドを追加するだけではなく、既存の実装を上書きするmonkey patchのようなものもプラグインとして追加することができます。
4848

49-
## どういう用途に向いていない?
49+
## どのような用途に向いていない?
5050

5151
これもJavaScriptのprototypeと同様で、prototypeによる拡張は柔軟すぎるため、
5252
jQuery自体がプラグインのコントロールをすることは難しいです。

Diff for: package.json

+7-6
Original file line numberDiff line numberDiff line change
@@ -24,6 +24,7 @@
2424
"eslint": "eslint src/**/*.js",
2525
"eslint:md": "summary-to-path | xargs eslint -c .md.eslintrc --ext .md",
2626
"textlint": "summary-to-path | xargs textlint -f pretty-error",
27+
"textlint:fix": "summary-to-path | xargs textlint --fix",
2728
"test:example": "find ./src -name '*-example.js' | xargs babel-node",
2829
"test:js": "mocha",
2930
"test": "npm-run-all --parallel test:js test:example textlint eslint:md eslint build",
@@ -43,25 +44,25 @@
4344
"babel-register": "^6.9.0",
4445
"codecov.io": "^0.1.6",
4546
"connect": "^3.4.0",
46-
"eslint": "^2.3.0",
47+
"eslint": "^3.10.2",
4748
"eslint-plugin-markdown": "^1.0.0-beta",
4849
"gitbook-cli": "^2.1.2",
4950
"gitbook-plugin-edit-link": "^2.0.0",
5051
"gitbook-plugin-ga": "^1.0.0",
5152
"gitbook-plugin-github": "^2.0.0",
52-
"gitbook-plugin-include-codeblock": "^1.9.0",
53+
"gitbook-plugin-include-codeblock": "^2.1.0",
5354
"gitbook-plugin-japanese-support": "0.0.1",
5455
"gitbook-plugin-richquotes": "0.0.7",
5556
"gitbook-summary-to-path": "^1.0.1",
5657
"jsdom": "^9.2.1",
5758
"lcov-summary": "^1.0.1",
58-
"mocha": "^2.2.5",
59+
"mocha": "^3.1.2",
5960
"nlcst-to-string": "^2.0.0",
6061
"node-fetch": "^1.3.2",
61-
"npm-run-all": "^2.1.1",
62+
"npm-run-all": "^3.1.1",
6263
"power-assert": "^1.4.1",
6364
"redux": "^3.5.2",
64-
"remark": "^5.0.1",
65+
"remark": "^6.2.0",
6566
"stemming-x-keywords": "^1.0.3",
6667
"textlint": "^7.0.0",
6768
"textlint-filter-rule-comments": "^1.2.1",
@@ -84,7 +85,7 @@
8485
"textlint-rule-sentence-length": "^1.0.4",
8586
"textlint-rule-spellcheck-tech-word": "^5.0.0",
8687
"textlint-rule-unexpanded-acronym": "^1.2.0",
87-
"unist-util-is": "^1.0.0",
88+
"unist-util-is": "^2.0.0",
8889
"unist-util-parents": "^0.1.1",
8990
"unist-util-select": "^1.0.0"
9091
},

0 commit comments

Comments
 (0)