teratail
回答率
85.35%
teratail header banner
teratail header banner
質問するログイン新規登録
トップnpmに関する質問フロントエンドのパッケージ管理にnpmを使用するのは正しいのでしょうか？

編集履歴

回答編集履歴

2

質問への回答に寄り添った感じに構成を変更

2020/03/19 07:51

投稿

miyabi-sun
miyabi-sun

スコア21203

test CHANGED
@@ -1,4 +1,40 @@
1
+ > Node.jsのパッケージを管理するツールでなぜフロントエンドのパッケージをインストールすることができるのでしょうか？
2
+
3
+
4
+
5
+ npmでNode.jsとJavaScriptのライブラリを両方管理するのが現状の主流です。
6
+
7
+
8
+
9
+ しかし、別れてないのキモいですよね。
10
+
11
+ Bowerというフロントエンド用のパッケージ管理ソフトもありましたが廃れました。
12
+
13
+ 参考記事: [Bowerはなぜオワコン化したのか - Qiita](https://qiita.com/jonghyo/items/e931f7b6357995314599)
14
+
15
+
16
+
17
+ これはNode.jsのrequireをJavaScriptに持ち出す
18
+
19
+ Browserifyやwebpackライブラリの功績でしょう。
20
+
21
+ 別にrequire使えるんだからnpmでいいじゃんという風潮に固まったのが原因と考えられます。
22
+
23
+
24
+
25
+ おもしろいですね。
26
+
27
+ 確かに日付を扱う[Moment.js](https://momentjs.com/)や、値をスマートに加工する[Lodash](https://lodash.com/docs/)といったライブラリは、
28
+
29
+ Node.jsとJavaScriptのどちらでも使いますので、ライブラリ作成者としては余り嬉しく無いポイントですね。
30
+
31
+
32
+
33
+ ---
34
+
35
+
36
+
1
- JavaScriptとNode.jsの違いに関して先に説明します。
37
+ JavaScriptとNode.jsの違いに関して歴史をふまえながら説明していきます。
2
38
 
3
39
 
4
40
 
@@ -18,7 +54,7 @@
18
54
 
19
55
  このV8エンジンにC++で作ったファイルを読み書きするモジュールや、インターネットに接続するモジュールを繋ぎ合わせて作りました。
20
56
 
21
- これがNode.jsという言語です。
57
+ これがNode.jsです。
22
58
 
23
59
 
24
60
 
@@ -72,98 +108,40 @@
72
108
 
73
109
  しかし`function require(path) {}`という風に自作関数を作れば
74
110
 
75
- require関数を利用する事は可能です。
111
+ require関数が宣言されていないというエラーは回避出来ます。
112
+
113
+ Browserifyやwebpackというライブラリは自作のrequire関数を用意します。
76
114
 
77
115
 
78
116
 
79
- Browserifyやwebpackというライブラリは、
117
+ 配信したいJavaScriptのコードをbundle.jsというファイルにしますが、
80
118
 
81
- 配信したいJavaScriptのコードをbundle.jsというファイルに固めますが、
82
-
83
- ソースコード上にあるrequireを静的解析し、依存モジュールも含めてbundle.jsに取り込んでしまいます。
119
+ この時、ソースコード上にあるrequireを静的解析し、依存モジュールも含めてbundle.jsに取り込んでしまいます。
84
120
 
85
121
  そしてライブラリが用意した自作関数のrequire越しにロードして使うということを実現させました。
86
122
 
87
123
 
88
124
 
89
- こういった力技で、JavaScriptでもrequireを使ってnpmのライブラリを扱う事に成功したのです。
125
+ 人類はJavaScriptでもrequireを使ってnpmのライブラリを扱う事に成功したのです。
90
126
 
91
- ただしNode.jsのrequireとは違い、下記2点に対応出来ません。
127
+ ただしNode.jsのrequireとは違い、下記のような事ができない成約があるので注意しましょう。
92
128
 
93
129
 
94
130
 
131
+ - 動的なrequireに対応出来ない
132
+
95
133
  - C++で追加されたライブラリは扱えない
96
-
97
- - 動的なrequireに対応出来ない
98
134
 
99
135
 
100
136
 
137
+ 前者は静的にrequire文を読み取っているのでそういう仕様になっています。
138
+
139
+ Node.jsも余りお行儀が良いわけではないので、コーディング規約等で禁止しているプロジェクトも存在します。
140
+
141
+
142
+
101
- 前者はファイルの読み書きやネットワーク通信のモジュールなんかの話です。
143
+ 後者はファイルの読み書きやネットワーク通信のモジュールなんかの話です。
102
144
 
103
145
  npmでフロントエンド用のライブラリを入手する際は、
104
146
 
105
147
  プロジェクトの説明書きを読んだりして、Node.jsとJavaScriptどちらに向けてのライブラリなのかを理解して使う必要があります。
106
-
107
-
108
-
109
- require部分を静的解析する都合でfor文やmapなんかを利用して、
110
-
111
- 不特定多数のコードを読み込む事は出来ません。
112
-
113
-
114
-
115
- ```js
116
-
117
- // お行儀が悪いのでNode.jsでも非推奨だったりする
118
-
119
- const modules = ["a.js", "b.js"];
120
-
121
- for (const name of modudles) {
122
-
123
- require("./" + name);
124
-
125
- }
126
-
127
- ```
128
-
129
-
130
-
131
- ---
132
-
133
-
134
-
135
- > Node.jsのパッケージを管理するツールでなぜフロントエンドのパッケージをインストールすることができるのでしょうか？
136
-
137
-
138
-
139
- 別れてないのキモいですよね。
140
-
141
- 元々はBowerというフロントエンド用のパッケージ管理ソフトもありました。
142
-
143
- もう廃れてるのでそれに関する記事だけ紹介しておきます。
144
-
145
-
146
-
147
- 参考記事: [Bowerはなぜオワコン化したのか - Qiita](https://qiita.com/jonghyo/items/e931f7b6357995314599)
148
-
149
-
150
-
151
- Browserifyやwebpackという強力な後押しにより
152
-
153
- 別にnpmでいいじゃんという風潮に固まりました。
154
-
155
-
156
-
157
- おもしろいですね。
158
-
159
- 確かに日付を扱う[Moment.js](https://momentjs.com/)や、
160
-
161
- 値をスマートに加工する[Lodash](https://lodash.com/docs/)なんかは
162
-
163
- Node.jsとJavaScriptのどちらでも使います。
164
-
165
-
166
-
167
- パッケージが別れてるってのは面倒だと思います。
168
-
169
- その辺がパッケージの統合に繋がったのかもしれませんね。

1

文章校正

2020/03/19 07:51

投稿

miyabi-sun
miyabi-sun

スコア21203

test CHANGED
@@ -2,21 +2,23 @@
2
2
 
3
3
 
4
4
 
5
- ブラウザで動作してロードしたHTMLを後から編集して、
5
+ ブラウザで動作してロードしたHTML(DOMツリー)を後から編集して、
6
6
 
7
- 画面の変更を促す為に作られたスクリプト言語がJavaScriptです。
7
+ 画面の変更を促すスクリプト言語がJavaScriptです。
8
8
 
9
- なので、ファイルを保存したり、好き勝手にインターネットに繋ぐような機能は存在しません。
9
+ ファイルを保存したり、好き勝手にインターネットに繋ぐような機能は不要なので存在しません。
10
+
11
+ (HTML5と同時にいくらかは解禁されましたが、セキュリティの問題もあり、かなり使い勝手が悪いものになります)
10
12
 
11
13
 
12
14
 
13
- でも、これをRubyのように使いたいんだ！と有志が
15
+ で、これをRubyのような汎用スクリプト言語として使いたいんだ！と有志が立ち上がりました。
14
16
 
15
- Google ChromeのJavaScriptエンジン(V8)を利用して、
17
+ Google ChromeのJavaScriptエンジン(V8)はオープンソースで配布されています。
16
18
 
17
- C++で作ったファイルを読み書きするモジュールや、インターネットに接続するモジュールを繋ぎ合わせて
19
+ このV8エンジンにC++で作ったファイルを読み書きするモジュールや、インターネットに接続するモジュールを繋ぎ合わせて作りました。
18
20
 
19
- Rubyのような汎用言語として完成させたものがNode.jsです。
21
+ これがNode.jsという言語です。
20
22
 
21
23
 
22
24
 
@@ -24,29 +26,27 @@
24
26
 
25
27
 
26
28
 
27
- JavaScriptにはファイルを読み書きする機能がありませんので、
29
+ JavaScriptはファイルを読み書きする機能がありませんので、
28
30
 
29
31
  jQuery等のライブラリではグローバル変数領域に保存する作りになっています。
30
32
 
31
- `windows.$ = function () {}`みたいな事をやっているんですね。
33
+ `windows.$ = function () {}`みたいな感じで、グローバル変数領域が汚れるのが欠点。
32
34
 
33
35
 
34
36
 
35
- Node.jsを作る時にライブラリをロードして使えないのは不便なので、
37
+ Node.jsは[CommonJS](https://ja.wikipedia.org/wiki/CommonJS)の考え方を拝借して、
36
38
 
37
- [CommonJS](https://ja.wikipedia.org/wiki/CommonJS)の考え方を拝借して、
38
-
39
- `require`という関数を用意したんですね。
39
+ `require`という関数を用意してグローバル変数領域を汚さない仕組みを構築しました。
40
40
 
41
41
 
42
42
 
43
- requireを使えばnode_modulesフォルダを探して何時でも好きなタイミングで関数等の情報を入手できます。
43
+ requireは実行したタイミングでnode_modulesフォルダを探して関数やオブジェクトを持ち帰ってくれます。
44
44
 
45
- node_modules配下のライブラリはnpmというパッケージ管理ツールでメンテナンス可能です。
45
+ node_modules配下のライブラリはnpmというパッケージ管理ツールでメンテナンスできるようになっています。
46
46
 
47
47
 
48
48
 
49
- なのでNode.jsはとっても便利！
49
+ Node.jsはモジュールの管理がしやすくてとっても便利！
50
50
 
51
51
  JavaScriptは不便……
52
52
 
@@ -62,25 +62,69 @@
62
62
 
63
63
 
64
64
 
65
- JavaScriptのコードにrequireという自作関数を無理やり追加し、
65
+ まずWebサーバで配信したいJavaScriptをNode.jsを記述しておきます。
66
66
 
67
- 配信したいJavaScriptのコードをbundle.jsというファイルに固めます。
67
+ しかしJavaScriptにはrequire関数がないので、
68
68
 
69
- このbundle.jsを作るタイミングでrequire部分を静的解析し、
69
+ このままではエラーで落ちてしまいます。
70
70
 
71
+
72
+
73
+ しかし`function require(path) {}`という風に自作関数を作れば
74
+
75
+ require関数を利用する事は可能です。
76
+
77
+
78
+
79
+ Browserifyやwebpackというライブラリは、
80
+
81
+ 配信したいJavaScriptのコードをbundle.jsというファイルに固めますが、
82
+
71
- 該当のモジュールをコピペしてbundle.jsにまるっと取り込んでしまうわけです。
83
+ ソースコード上にあるrequireを静的解析し、依存モジュールも含めてbundle.jsに取り込んでしまいます。
84
+
85
+ そしてライブラリが用意した自作関数のrequire越しにロードして使うということを実現させました。
72
86
 
73
87
 
74
88
 
75
89
  こういった力技で、JavaScriptでもrequireを使ってnpmのライブラリを扱う事に成功したのです。
76
90
 
77
- ただしNode.jsで足されたC++に依存するライブラリは扱えません。
91
+ ただしNode.jsのrequireとは違い、下記2点に対応出来ません。
78
92
 
79
93
 
80
94
 
81
- なのでnpmでフロントエンド用のライブラリを入手する際は、
95
+ - C++で追加されたライブラリは扱えない
82
96
 
97
+ - 動的なrequireに対応出来ない
98
+
99
+
100
+
101
+ 前者はファイルの読み書きやネットワーク通信のモジュールなんかの話です。
102
+
103
+ npmでフロントエンド用のライブラリを入手する際は、
104
+
83
- README.md等の説明書きを読んだりして、これはNode.jsとJavaScriptどちらに向けてのライブラリなのかを理解して使う必要があります。
105
+ プロジェクトの説明書きを読んだりして、Node.jsとJavaScriptどちらに向けてのライブラリなのかを理解して使う必要があります。
106
+
107
+
108
+
109
+ require部分を静的解析する都合でfor文やmapなんかを利用して、
110
+
111
+ 不特定多数のコードを読み込む事は出来ません。
112
+
113
+
114
+
115
+ ```js
116
+
117
+ // お行儀が悪いのでNode.jsでも非推奨だったりする
118
+
119
+ const modules = ["a.js", "b.js"];
120
+
121
+ for (const name of modudles) {
122
+
123
+ require("./" + name);
124
+
125
+ }
126
+
127
+ ```
84
128
 
85
129
 
86
130
 
@@ -94,7 +138,7 @@
94
138
 
95
139
  別れてないのキモいですよね。
96
140
 
97
- なので、元々はBowerというフロントエンド用のパッケージ管理ソフトもありました。
141
+ 元々はBowerというフロントエンド用のパッケージ管理ソフトもありました。
98
142
 
99
143
  もう廃れてるのでそれに関する記事だけ紹介しておきます。
100
144
 
@@ -104,7 +148,7 @@
104
148
 
105
149
 
106
150
 
107
- しかし、Browserifyやwebpackという強力な後押しにより
151
+ Browserifyやwebpackという強力な後押しにより
108
152
 
109
153
  別にnpmでいいじゃんという風潮に固まりました。
110
154
 
@@ -112,6 +156,14 @@
112
156
 
113
157
  おもしろいですね。
114
158
 
115
- まぁ、確かに日付を扱う[Moment.js](https://momentjs.com/)や値をメソッドチェーンでかっこよく変更する[Lodash](https://lodash.com/docs/)なんかは
159
+ 確かに日付を扱う[Moment.js](https://momentjs.com/)や、
116
160
 
161
+ 値をスマートに加工する[Lodash](https://lodash.com/docs/)なんかは
162
+
117
- Node.jsとJavaScriptのどちらでも使えたら嬉しいわけで、パッケージが別れてるってのは面倒ですからね。
163
+ Node.jsとJavaScriptのどちらでも使います。
164
+
165
+
166
+
167
+ パッケージが別れてるってのは面倒だと思います。
168
+
169
+ その辺がパッケージの統合に繋がったのかもしれませんね。