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

編集履歴

回答編集履歴

2

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

2020/03/19 07:51

投稿

miyabi-sun
miyabi-sun

スコア21461

answer CHANGED
@@ -1,5 +1,23 @@
1
- JavaScriptとNode.jsの違いに関して先に説明します。
1
+ > Node.jsのパッケージを管理するツールでなぜフロントエンドのパッケージをインストールすることができるのでしょうか？
2
2
 
3
+ npmでNode.jsとJavaScriptのライブラリを両方管理するのが現状の主流です。
4
+
5
+ しかし、別れてないのキモいですよね。
6
+ Bowerというフロントエンド用のパッケージ管理ソフトもありましたが廃れました。
7
+ 参考記事: [Bowerはなぜオワコン化したのか - Qiita](https://qiita.com/jonghyo/items/e931f7b6357995314599)
8
+
9
+ これはNode.jsのrequireをJavaScriptに持ち出す
10
+ Browserifyやwebpackライブラリの功績でしょう。
11
+ 別にrequire使えるんだからnpmでいいじゃんという風潮に固まったのが原因と考えられます。
12
+
13
+ おもしろいですね。
14
+ 確かに日付を扱う[Moment.js](https://momentjs.com/)や、値をスマートに加工する[Lodash](https://lodash.com/docs/)といったライブラリは、
15
+ Node.jsとJavaScriptのどちらでも使いますので、ライブラリ作成者としては余り嬉しく無いポイントですね。
16
+
17
+ ---
18
+
19
+ JavaScriptとNode.jsの違いに関して歴史をふまえながら説明していきます。
20
+
3
21
  ブラウザで動作してロードしたHTML(DOMツリー)を後から編集して、
4
22
  画面の変更を促すスクリプト言語がJavaScriptです。
5
23
  ファイルを保存したり、好き勝手にインターネットに繋ぐような機能は不要なので存在しません。
@@ -8,7 +26,7 @@
8
26
  で、これをRubyのような汎用スクリプト言語として使いたいんだ！と有志が立ち上がりました。
9
27
  Google ChromeのJavaScriptエンジン(V8)はオープンソースで配布されています。
10
28
  このV8エンジンにC++で作ったファイルを読み書きするモジュールや、インターネットに接続するモジュールを繋ぎ合わせて作りました。
11
- これがNode.jsという言語です。
29
+ これがNode.jsです。
12
30
 
13
31
  ---
14
32
 
@@ -35,51 +53,22 @@
35
53
  このままではエラーで落ちてしまいます。
36
54
 
37
55
  しかし`function require(path) {}`という風に自作関数を作れば
38
- require関数を利用する事は可能です。
56
+ require関数が宣言されていないというエラーは回避出来ます。
57
+ Browserifyやwebpackというライブラリは自作のrequire関数を用意します。
39
58
 
40
- Browserifyやwebpackというライブラリは、
41
- 配信したいJavaScriptのコードをbundle.jsというファイルに固めますが、
59
+ 配信したいJavaScriptのコードをbundle.jsというファイルにしますが、
42
- ソースコード上にあるrequireを静的解析し、依存モジュールも含めてbundle.jsに取り込んでしまいます。
60
+ この時、ソースコード上にあるrequireを静的解析し、依存モジュールも含めてbundle.jsに取り込んでしまいます。
43
61
  そしてライブラリが用意した自作関数のrequire越しにロードして使うということを実現させました。
44
62
 
45
- こういった力技で、JavaScriptでもrequireを使ってnpmのライブラリを扱う事に成功したのです。
63
+ 人類はJavaScriptでもrequireを使ってnpmのライブラリを扱う事に成功したのです。
46
- ただしNode.jsのrequireとは違い、下記2点に対応出来ません。
64
+ ただしNode.jsのrequireとは違い、下記のような事ができない成約があるので注意しましょう。
47
65
 
66
+ - 動的なrequireに対応出来ない
48
67
  - C++で追加されたライブラリは扱えない
49
- - 動的なrequireに対応出来ない
50
68
 
69
+ 前者は静的にrequire文を読み取っているのでそういう仕様になっています。
70
+ Node.jsも余りお行儀が良いわけではないので、コーディング規約等で禁止しているプロジェクトも存在します。
71
+
51
- 前者はファイルの読み書きやネットワーク通信のモジュールなんかの話です。
72
+ 後者はファイルの読み書きやネットワーク通信のモジュールなんかの話です。
52
73
  npmでフロントエンド用のライブラリを入手する際は、
53
- プロジェクトの説明書きを読んだりして、Node.jsとJavaScriptどちらに向けてのライブラリなのかを理解して使う必要があります。
74
+ プロジェクトの説明書きを読んだりして、Node.jsとJavaScriptどちらに向けてのライブラリなのかを理解して使う必要があります。
54
-
55
- require部分を静的解析する都合でfor文やmapなんかを利用して、
56
- 不特定多数のコードを読み込む事は出来ません。
57
-
58
- ```js
59
- // お行儀が悪いのでNode.jsでも非推奨だったりする
60
- const modules = ["a.js", "b.js"];
61
- for (const name of modudles) {
62
- require("./" + name);
63
- }
64
- ```
65
-
66
- ---
67
-
68
- > Node.jsのパッケージを管理するツールでなぜフロントエンドのパッケージをインストールすることができるのでしょうか？
69
-
70
- 別れてないのキモいですよね。
71
- 元々はBowerというフロントエンド用のパッケージ管理ソフトもありました。
72
- もう廃れてるのでそれに関する記事だけ紹介しておきます。
73
-
74
- 参考記事: [Bowerはなぜオワコン化したのか - Qiita](https://qiita.com/jonghyo/items/e931f7b6357995314599)
75
-
76
- Browserifyやwebpackという強力な後押しにより
77
- 別にnpmでいいじゃんという風潮に固まりました。
78
-
79
- おもしろいですね。
80
- 確かに日付を扱う[Moment.js](https://momentjs.com/)や、
81
- 値をスマートに加工する[Lodash](https://lodash.com/docs/)なんかは
82
- Node.jsとJavaScriptのどちらでも使います。
83
-
84
- パッケージが別れてるってのは面倒だと思います。
85
- その辺がパッケージの統合に繋がったのかもしれませんね。

1

文章校正

2020/03/19 07:51

投稿

miyabi-sun
miyabi-sun

スコア21461

answer CHANGED
@@ -1,28 +1,28 @@
1
1
  JavaScriptとNode.jsの違いに関して先に説明します。
2
2
 
3
- ブラウザで動作してロードしたHTMLを後から編集して、
3
+ ブラウザで動作してロードしたHTML(DOMツリー)を後から編集して、
4
- 画面の変更を促す為に作られたスクリプト言語がJavaScriptです。
4
+ 画面の変更を促すスクリプト言語がJavaScriptです。
5
- なので、ファイルを保存したり、好き勝手にインターネットに繋ぐような機能は存在しません。
5
+ ファイルを保存したり、好き勝手にインターネットに繋ぐような機能は不要なので存在しません。
6
+ (HTML5と同時にいくらかは解禁されましたが、セキュリティの問題もあり、かなり使い勝手が悪いものになります)
6
7
 
7
- でも、これをRubyのように使いたいんだ！と有志が
8
+ で、これをRubyのような汎用スクリプト言語として使いたいんだ！と有志が立ち上がりました。
8
- Google ChromeのJavaScriptエンジン(V8)を利用して、
9
+ Google ChromeのJavaScriptエンジン(V8)はオープンソースで配布されています。
9
- C++で作ったファイルを読み書きするモジュールや、インターネットに接続するモジュールを繋ぎ合わせて
10
+ このV8エンジンにC++で作ったファイルを読み書きするモジュールや、インターネットに接続するモジュールを繋ぎ合わせて作りました。
10
- Rubyのような汎用言語として完成させたものがNode.jsです。
11
+ これがNode.jsという言語です。
11
12
 
12
13
  ---
13
14
 
14
- JavaScriptにはファイルを読み書きする機能がありませんので、
15
+ JavaScriptはファイルを読み書きする機能がありませんので、
15
16
  jQuery等のライブラリではグローバル変数領域に保存する作りになっています。
16
- `windows.$ = function () {}`みたいな事をやっているんですね。
17
+ `windows.$ = function () {}`みたいな感じで、グローバル変数領域が汚れるのが欠点。
17
18
 
18
- Node.jsを作る時にライブラリをロードして使えないのは不便なので、
19
- [CommonJS](https://ja.wikipedia.org/wiki/CommonJS)の考え方を拝借して、
19
+ Node.jsは[CommonJS](https://ja.wikipedia.org/wiki/CommonJS)の考え方を拝借して、
20
- `require`という関数を用意したんですね。
20
+ `require`という関数を用意してグローバル変数領域を汚さない仕組みを構築しました。
21
21
 
22
- requireを使えばnode_modulesフォルダを探して何時でも好きなタイミングで関数等の情報を入手できます。
22
+ requireは実行したタイミングでnode_modulesフォルダを探して関数やオブジェクトを持ち帰ってくれます。
23
- node_modules配下のライブラリはnpmというパッケージ管理ツールでメンテナンス可能です。
23
+ node_modules配下のライブラリはnpmというパッケージ管理ツールでメンテナンスできるようになっています。
24
24
 
25
- なのでNode.jsはとっても便利！
25
+ Node.jsはモジュールの管理がしやすくてとっても便利！
26
26
  JavaScriptは不便……
27
27
 
28
28
  ---
@@ -30,30 +30,56 @@
30
30
  JavaScriptでもrequireを使いたい！
31
31
  Browserifyやwebpackというプロジェクトが始動しました。
32
32
 
33
+ まずWebサーバで配信したいJavaScriptをNode.jsを記述しておきます。
33
- JavaScriptのコードにrequireという自作関数を無理やり追加し、
34
+ しかしJavaScriptにはrequire関数がないので、
34
- 配信したいJavaScriptのコードをbundle.jsというファイルに固めます。
35
- このbundle.jsを作るタイミングでrequire部分を静的解析し、
36
- 該当のモジュールをコピペしてbundle.jsにまるっと取り込んでしまうわけです。
35
+ このままではエラーで落ちてしまいます。
37
36
 
37
+ しかし`function require(path) {}`という風に自作関数を作れば
38
+ require関数を利用する事は可能です。
39
+
40
+ Browserifyやwebpackというライブラリは、
41
+ 配信したいJavaScriptのコードをbundle.jsというファイルに固めますが、
42
+ ソースコード上にあるrequireを静的解析し、依存モジュールも含めてbundle.jsに取り込んでしまいます。
43
+ そしてライブラリが用意した自作関数のrequire越しにロードして使うということを実現させました。
44
+
38
45
  こういった力技で、JavaScriptでもrequireを使ってnpmのライブラリを扱う事に成功したのです。
39
- ただしNode.jsで足されたC++に依存するライブラリは扱えません。
46
+ ただしNode.jsのrequireとは違い、下記2点に対応出来ません。
40
47
 
41
- なのでnpmでフロントエンド用のライブラリを入手する際は、
48
+ - C++で追加されたライブラリは扱えない
42
- README.md等の説明書きを読んだりして、これはNode.jsとJavaScriptどちらに向けてのライブラリなのかを理解して使う必要があります。
49
+ - 動的なrequireに対応出来ない
43
50
 
51
+ 前者はファイルの読み書きやネットワーク通信のモジュールなんかの話です。
52
+ npmでフロントエンド用のライブラリを入手する際は、
53
+ プロジェクトの説明書きを読んだりして、Node.jsとJavaScriptどちらに向けてのライブラリなのかを理解して使う必要があります。
54
+
55
+ require部分を静的解析する都合でfor文やmapなんかを利用して、
56
+ 不特定多数のコードを読み込む事は出来ません。
57
+
58
+ ```js
59
+ // お行儀が悪いのでNode.jsでも非推奨だったりする
60
+ const modules = ["a.js", "b.js"];
61
+ for (const name of modudles) {
62
+ require("./" + name);
63
+ }
64
+ ```
65
+
44
66
  ---
45
67
 
46
68
  > Node.jsのパッケージを管理するツールでなぜフロントエンドのパッケージをインストールすることができるのでしょうか？
47
69
 
48
70
  別れてないのキモいですよね。
49
- なので、元々はBowerというフロントエンド用のパッケージ管理ソフトもありました。
71
+ 元々はBowerというフロントエンド用のパッケージ管理ソフトもありました。
50
72
  もう廃れてるのでそれに関する記事だけ紹介しておきます。
51
73
 
52
74
  参考記事: [Bowerはなぜオワコン化したのか - Qiita](https://qiita.com/jonghyo/items/e931f7b6357995314599)
53
75
 
54
- しかし、Browserifyやwebpackという強力な後押しにより
76
+ Browserifyやwebpackという強力な後押しにより
55
77
  別にnpmでいいじゃんという風潮に固まりました。
56
78
 
57
79
  おもしろいですね。
80
+ 確かに日付を扱う[Moment.js](https://momentjs.com/)や、
58
- まぁ、確かに日付を扱う[Moment.js](https://momentjs.com/)や値をメソッドチェーンでかっこよく変更する[Lodash](https://lodash.com/docs/)なんかは
81
+ 値をスマートに加工する[Lodash](https://lodash.com/docs/)なんかは
59
- Node.jsとJavaScriptのどちらでも使えたら嬉しいわけで、パッケージが別れてるってのは面倒ですからね。
82
+ Node.jsとJavaScriptのどちらでも使います。
83
+
84
+ パッケージが別れてるってのは面倒だと思います。
85
+ その辺がパッケージの統合に繋がったのかもしれませんね。