20201019のNode.jsに関する記事は6件です。

【npm】nodistによるNode.jsとnpmのバージョン管理

要約

AngularやExpressといったNode.jsをテーマとするweb教材では、Node.jsをNode.jsの公式サイトからインストールすることが多いです。しかし、この方法ではNode.jsの管理ができず、以後の学習に困ってしまいます。そこで、まずはNode.jsのバージョン管理ツールであるnodistをインストール、次にNode.jsをインストール、最後に必要なnpmパッケージをインストールするという方法のほうが長期的にはベターだと思います。この記事ではこの方法について解説します。

~nodist, Node.js, npm angular/cliの関係イメージ~

※Angular CLIに関しては、ご自身の必要なnpmパッケージに置き換えて考えていただければと思います。

image-20201019212955021.png


環境


手順

手順は大きく4つになります。

  1. Node.jsをアンインストールする

  2. nodistをインストールする

  3. nodistからNode.jsとnpmをバージョン指定してインストールする

  4. Angular CLIをインストールする

以下、順に説明します。


1. Node.jsをアンインストールする

まずは、公式からインストールしたNode.jsをアンインストールしておきましょう。

コントロールパネルのプログラムのアンインストールまたは変更から、Node.jsをアンインストールしてください。

image-20201019143931813.png


2. nodistをインストールする

次に、nodistをインストールします。

nodistのサイトにアクセスしてください。

NodistSetup-v0.9.1.exeをクリックしてください。※2020/10/19時点のバージョンです

image-20201019143817165.png

exeファイルを実行し、案内に従い、nodistをインストールします。

インストールの確認をしましょう。コマンドプロンプトを開き、以下のコマンドを実行します。

nodist -v

このコマンドは、nodistのバージョンを表示します。バージョンが表示されれば(私の場合は、0.9.1です)nodistのインストールは完了しています。


3. nodistからNode.jsとnpmをバージョン指定してインストールする

次に、nodistを使ってNode.jsとnpmをバージョンを指定してインストールします。

nodistをインストールしたとき、すでにNode.jsはインストールされています。

コマンドプロンプトを開き、以下のコマンドを実行します。

node -v

このコマンドは、Node.jsのバージョンを表示します。私の場合は11.13.0でした。奇数バージョンは最新機能が利用できますが、安定したシステムの構築には不向きです。そこで、nodistを使ってNode.jsのバージョンを偶数系に変更してみましょう。

以下のコマンドを実行します。

nodist dist

このコマンドは、nodistでインストール可能なNode.jsのバージョン一覧を表示します。

image-20201019150614851.png

さて、これらのうちどのバージョンをインストールすればよいのでしょうか?

Node.jsのリリースサイトにアクセスしてみましょう。

以下、少しばかり引用します。

LTS release status is "long-term support", which typically guarantees that critical bugs will be fixed for a total of 30 months. Production applications should only use Active LTS or Maintenance LTS releases.

(日本語)LTSのリリースステータスは「長期サポート」です。これは通常、重大なバグが合計30か月間修正されることを保証します。実稼働アプリケーションでは、アクティブLTSまたはメンテナンスLTSリリースのみを使用する必要があります。

せっかくバージョン管理をするなら実稼働アプリケーションに使用できるものがいいと思います。つまりステータスがActive LTSまたはMaintenance LTSのバージョンがよいということになります。このサイトの下にはステータスのリストが表示されています。

image-20201019151239563.png

このリストから、v10系か、v12系をインストールすることが望ましいと判断できます。今回は、v12系の12.18.0をインストールします。

インストールすべきNode.jsのバージョンが分かったところで、以下のコマンドを実行します。

nodist 12.18.0

このコマンドは、バージョン12.18.0のNode.jsをインストールします。

バージョンを確認しましょう。以下のコマンドを実行します。

node -v

12.18.0と表示されていれば、Node.jsのバージョンを12.18.0に変更できています。

続いて、npmのバージョンも確認してみます。以下のコマンドを実行します。

npm -v

私の場合は、6.9.0がインストールされていました。さて、Node.jsのリリース一覧ページを見ると、先ほどインストールしたNode.jsのバージョン12.18.0に対応するnpmのバージョンは6.14.4です。

image-20201019151239563.png

なので、npmのバージョンを6.9.0から6.14.4に変更しておきましょう。以下のコマンドを実行します。

nodist npm 6.14.4

このコマンドは、バージョン6.14.4のnpmをインストールします。

最後にもう一度、以下のコマンドを実行して、npmのバージョンが変更できたかを確認しておきましょう。

npm -v

6.14.4と表示されていれば、npmのバージョンを6.14.4に変更できています。


4. Angular CLIをインストールする

最後に、Angular CLIをインストールします。

※この章は、ご自身が必要なnpmパッケージに置き換えて参考にしていただければと思います。

npm公式サイトにアクセスします。

angular cliで検索した結果によると、Angular CLIのバージョンは10.1.7だそうです。

また、このnpmパッケージには、バージョン8.9以上のNode.jsと、バージョン5.5.1以上のnpmが必要だそうです。

以下、引用します。

Prerequisites

Both the CLI and generated project have dependencies that require Node 8.9 or higher, together with NPM 5.5.1 or higher.

(日本語)

前提条件

CLIと生成されたプロジェクトの両方に、NPM5.5.1以降とともにノード8.9以降を必要とする依存関係があります。

今回インストールしたNode.jsとnpmは両方とも条件を満たしているので、大丈夫そうですね。

では、Angular CLIをインストールします。以下のコマンドを実行します。

npm install -g @angular/cli

このコマンドは、Angular CLIをグローバルインストールします。

最後に、Angular CLIのバージョンを確認しましょう。以下のコマンドを実行します。

ng version

このコマンドはAngular CLIのコマンドで、CLIのバージョンを表示します。

image-20201019220623147.png

Angular CLIのバージョンが10.1.7と確認できました。


おわりに

最後に今一度、ポイントをまとめておきます。

  • Node.jsを公式サイトから直接インストールすると、Node.jsのバージョン管理ができない
  • nodistは、Node.jsとnpmのバージョン管理ツールであり、バージョンを指定してインストールできる
  • Node.jsは、最新機能を使いたいなどのこだわりがなければLTS(Long Term Support)のバージョンを使用するのがよい
  • Node.jsとnpmは、対応するバージョンをインストールすべきである
  • プロジェクトで使用するnpmパッケージのNode.jsとnpmの依存関係を確認しておくこと

参考ページ

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

EC2でnode.jsサーバーを立てる時に最低限インストールするもの。

概要

EC2立てた後に、node.jsを入れる手順

インストールするもの

・nvm(必須) これはgitが必要なのであとでやる。
・git(必須)

1、yumでgitをインストールする

$ sudo yum install git

2、nvmをインストールする。

// git cloneする
$ git clone https://github.com/creationix/nvm.git ~/.nvm

// nvmへのパスを通す。
$ source ~/.nvm/nvm.sh

// ログアウト時にパスの設定が消えてしまうので.bash_profileに記述しておく
$ vi .bash_profile
→ファイルが開くので、下記を追加
# nvm
if [[ -s ~/.nvm/nvm.sh ]] ; then
        source ~/.nvm/nvm.sh ;
fi

3,node.jsをインストールする

// インストール可能なバージョンを確認する。
nvm ls-remote

//インストールして使用する
nvm install v12.19.0
nvm use v12.19.0

//きちんとインストールできていることを確認する
node -v
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Node.js: require()は同期型ロード、importは非同期型ロード

この投稿では、Node.jsにおいてCommonJSとES Modulesのモジュールロードの仕組みの違いを、同期的か非同期的かの観点で説明します。

本稿では、CommonJSはCJS、ES ModulesはESMと略称で記載します。

:bow: 執筆にあたり、できるだけ努力して調査したつもりですが、もし用語の使い間違いや誤った説明などがございましたら、ご指摘や訂正の提案などを頂けると幸いです。

同期的なCJS、非同期的なESM

CJSはもともとサーバサイドJavaScriptにおけるモジュールの問題を解決するためにねられた仕様でした。サーバサイドではJSファイルがローカルディスク上にあることが普通です。そのため、JSファイルを探し、ファイルの内容を読み込む処理はCJSでは同期的なロード方式になっています。

一方の、ESMはサーバサイドだけでなく、ブラウザで使われることも考えて、同期的なロード方法に限定しないことになっています。もしも、同期的なロードに限定してしまうと、ブラウザでのユーザ体験が悪くなるからです。

ESMのロード方式を同期的な実装にするか、非同期的にするかは、JavaScriptの実行エンジンが決めていいことになっています。Node.jsは、ESMは非同期的にロードする方式を採用しています。

ファイル読み込みと実行

モジュールのロードプロセスは基本的に、JavaScriptのファイルを読み込み実行されるわけですが、ファイル読み込みと実行のタイミングはCJSとESMで異なってきます。

CJSのファイル読み込みと実行

CJSでは、モジュールをrequireしたとき、モジュールごとに「ファイル読み込み」→「実行」の手続きをセットで行っていきます。

例えば、次の例のように3つのモジュールをrequireしているコードで具体的に考えてみましょう:

// 1.js
console.log("1.js");

// 2.js
console.log("2.js");

// 3.js
console.log("3.js");

// cjs.js
require("./1");
require("./2");
require("./3");

このcjs.jsを動かすと、ロードプロセスはどんな流れで進んでいくでしょうか。まず、1行目でrequireした1.jsのファイルの内容が読み込まれます。そして、そのJavaScriptコードが評価実行されます。ここで、コンソールの標準出力に1.js\nが出力されます。次に、2.jsが読み込まれ、実行、2.js\nが出力されます。最後に、3.jsが読み込まれ、実行、3.js\nが出力されます。

mjqr35538ahk8o6v8p5niscfj7nc.png

ちなみに、CJSのロードプロセスが実際にどうなっているかは、環境変数NODE_DEBUG=moduleをセットしてNode.jsを実行してみると観察することができます。

7esdbky214p0ke717qgumowjdk6y.png

CJSが同期的と言われるのは、このようにモジュールのファイル読み込みと実行が同時期に発生しながらロードプロセスが進んでいくためです。

ESMのファイル読み込みと実行

Node.jsのESMでは、モジュールをimportしたとき、非同期的なロードを行うようになっています。なぜ非同期かというと、モジュールのファイル読み込み、依存関係グラフの構築、そして、実行がバラバラのタイミングで行われるためです。

具体的に、次のように3つのモジュールをimportしているコードを見てみましょう:

// 1.mjs
console.log("1.mjs");

// 2.mjs
console.log("2.mjs");

// 3.mjs
console.log("3.mjs");

// esm.mjs
import "./1.mjs";
import "./2.mjs";
import "./3.mjs";

このesm.mjsを動かすと、モジュールのロードプロセスは次のようになります。まず、esm.mjs自体が読み込まれ、静的解析され、依存するモジュールのリストが作られます。この時点では、esm.mjs自体はまだ実行されません。

1.mjs、2.mjs、3.mjsがリストアップされるので、このリストに基づいて、3つファイルを並行で読み込みます。これらも静的解析され、依存するモジュールのリストを作るのですが、これ以上依存先がないため、モジュールの依存関係グラフが完成します。

5mj3nwvxnh2wbgyhbaakks64mdcl.png

最後にそのグラフに基づいて、各モジュールを実行していきます。実行順は、post-order traversalというアルゴリズムで行われます。ざっくりいうと、グラフの中で末端かつ左側に位置するモジュールから実行していき、ルートに到達するまでそれを繰り返すというものです。

post-order traversalの探索順序

i5smrfy4wyi8ejxh02zkbkrwvsd6.gif

なので、この例では、まず1.mjsが実行され、コンソールの標準出力に1.mjs\nが出力されます。次に、2.mjsが実行され、2.mjs\nが出力されます。最後に、3.mjsが実行され、3.mjs\nが出力されます。そして最後にesm.mjsが実行されます。

e3w5k8bb6tiubfh7uouefeyndp42.png

ちなみに、ESMのロードプロセスが実際にどうなっているかは、環境変数NODE_DEBUG=esmをセットしてNode.jsを実行してみると観察することができます。

2k1scf9lrn23iea41pybg52n08k1.png

ESMローダーが非同期型であることのメリット

ESMのロード方式は、ECMAScriptの仕様で決められておらず、Node.jsが非同期的ロードなのはNode.jsがそう作ったからというのは前述したとおりです。Node.jsが同期的なローダーを実装する選択肢も無くはなかったわけですが、非同期を採用したことでいくつかメリットも生まれました。

メリット1: 並行読み込みによるパフォーマンス

CJSは同期的ロードなので、モジュールをロードし終わるまでは、別のモジュールをロードすることができません。ESMは非同期的なので、複数のモジュールを並行して読み込むことができます。このおかげで、読み込むモジュールが多くなるほど、パフォーマンスにいい影響を与えられると考えられます。

メリット2: リモートモジュール対応への将来性がある

Node.jsはブラウザと異なり、import "https://..."のようにして、リモートのモジュールをロードすることは現在できません。しかし、ESMローダーが非同期な設計になっているおかげで、リモートのモジュールをダウンロードしてきて実行することが、技術的には可能になっています。もしも、将来的にNode.jsがリモートモジュールに対応した場合、ローダーの仕様を変えないで済むので、Nodeユーザとしては下位互換性を崩されることなく、リモートモジュール対応の恩恵を享受できることでしょう。

メリット3: ブラウザのローダーと同じ

ブラウザはリモートモジュールをロードする必要があるので、非同期的なローダーになっています。Node.jsもブラウザと同じ非同期型であることはメリットです。モジュールを開発するとき、「ブラウザではこう、Node.jsではこう」と場合分けしてモジュールの設計を考えずに済みます。また、モジュールを使う側としても、同じマインドセットで臨めるので、学習コストがかからなかったり、知らぬがゆえにバグらせてしまうといった事故も避けられます。


最後までお読みくださりありがとうございました。Twitterでは、Qiitaに書かない技術ネタなどもツイートしているので、よかったらフォローお願いします:relieved:Twitter@suin

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Node.js のバージョン管理についてのメモ(nodebrew, nodenv)

Node.js 自体のバージョン管理は nodebrewnodenv などがありますが、お好みでいいと思います。

nodenv はディレクトリごとにバージョンを指定することが可能ですが、nodebrew でも必要に応じてバージョンを切り替えることができるので、そこまで困ることはありませんでした。

初心者であれば nodebrew をお勧めします。
nodebrew で困ることが発生してから nodenv に乗り換えるということでいいと思います。

【参考】
・ MacにNode.jsをnodebrewでインストールして環境構築【決定版】
・ MacにNode.jsをインストール
・ MacにNode.jsをインストール(anyenv + nodenv編)

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

スマホで写真撮る人は必読?スマホのフラッシュライト進化させます。

目的

スマホのフラッシュライト活用してる人いますか?
落とし物探すときに隙間照らすぐらいしかないですよね。

でも、写真を撮るときに光って大切なんです。(知らんけど)
なので、被写体との距離でライトの明るさを自動で調整できるようにしました。

この記事でできること

・node.jsでobnizを操作
・超音波測距センサ(HC-SR04 )で物体との距離を測る
・LEDライト(WS2811)を光らせ、明るさを調節する
・スマホがガジェット感出てかっこよくなる(気がする)

完成したらこんな感じ

スマホはこんな感じ
スマホ写真.jpg

動かしたらこんな感じ

コード

const Obniz = require('obniz');
const obniz = new Obniz(''); // Obniz_IDに自分のIDを入れます

obniz.onconnect = async function () {
    // RGB LEDを利用
    const rgbled = obniz.wired('WS2811', { gnd: 0, vcc: 1, din: 2 });
    // 超音波測距センサを利用する
    const hcsr04 = obniz.wired('HC-SR04', { gnd: 8, echo: 9, trigger: 10, vcc: 11});
    // ディスプレイ表示(初期画面)
    obniz.display.clear();
    obniz.display.print('Hello obniz!');

    // setIntervalで間隔を作る
    setInterval(async function () {
        // 距離を取得
        let distance = await hcsr04.measureWait();
        // 温度をコンソールに表示
        console.log(distance + ' mm');
        // obnizディスプレイに表示
        // 一度消してから距離+mmの単位を表示
        obniz.display.clear();
        obniz.display.print(distance + ' mm');
        if(distance > 2550){
            distance = 255;
        }
        rgbled.rgb(distance/10, distance/10, distance/10);
    }, 1000); // 1000ミリ秒 = 1秒
}

考察

スマホのフラッシュライト使ってない。

光センサも使って「周りの明るさ」+「被写体との距離」でライトの明るさを調整しようと思いましたが、光センサ断念してしまいました。

被写体との距離ですが、どことの距離を計測しているか視覚的に分かるようになれば、もっと正確に明るさを調整できそうです。

嫁さんとの心の距離も測れないですかね。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Node.jsのインストール

概要

  • MacにNode.jsをインストールする。
  • ターミナルでHomebrewを使ってインストールする。

前提

  • Homebrewをインストール済
  • ログインシェルがzsh

手順

  1. nodebrewをインストールする
  2. Node.jsをインストールする
  3. パスを通す

1. nodebrewをインストールする

下記を実行する

terminal
brew install nodebrew

※補足:nodebrewのバージョン確認

terminal
nodebrew -v

2. Node.jsをインストールする

2.1 nodebrewでNode.js(安定版)をインストールする

下記を実行する

terminal
nodebrew install-binary stable

※補足:下記のような結果が出て、インストールができなかった場合

terminal(結果)
Fetching: https://nodejs.org/dist/v14.14.0/node-v14.14.0-darwin-x64.tar.gz
Warning: Failed to create the file
Warning: /Users/[username]/.nodebrew/src/v14.14.0/node-v14.14.0-darwin-x64.tar
Warning: .gz: No such file or directory

curl: (23) Failed writing body (0 != 980)
download failed: https://nodejs.org/dist/v14.14.0/node-v14.14.0-darwin-x64.tar.gz

下記を実行する(.nodebrewディレクトリがない場合、-pオプションをつける)

terminal
mkdir -p ~/.nodebrew/src

その後、再度2.1を実行

2.2 インストールしたバージョンを使用するようにする

2.2.1 インストールしたバージョンを確認する

下記を実行する

terminal
nodebrew ls
terminal(結果)
v14.14.0

current: none

※「current: none」は、現在使用に指定しているバージョンはないという意味

2.2.2 インストールしたバージョンを使用するようにする

下記を実行する

terminal
nodebrew use v14.14.0

再度下記を実行

terminal
nodebrew ls

下記の通り、インストールしたバージョンが使用に指定されていることを確認

terminal(結果)
v14.14.0

current: v14.14.0

3. パスを通す

3.1 Node.jsを使えるように、下記を実行しパスを通す

terminal
echo "export PATH=$HOME/.nodebrew/current/bin:$PATH" >> ~/.zshrc

下記を実行し、ファイルを読み直す

terminal
source ~/.zshrc

3.2 使用可能かを確認する

下記を実行する

terminal
node -v

下記のような結果が出れば完了

terminal(結果)
v14.14.0
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む