What's New Qiita

20200801のNode.jsに関する記事は5件です。

  • 投稿日：2020-08-01T17:57:19+09:00

Could not find node.js. This will result in editors missing key features.となった時の対応方法

事象1 : Eclipseを使っていたらMissing node.jsってダイアログが出た

image.png

原因 : Node.jsがインストールするされていないから

最近はEclipse使うのにNode.jsが必要なのか・・・

エラーメッセージ
Could not find node.js. This will result in editors missing key features. Please make sure node.js is installed and that your PATH environment variable contains the location to the 'node' executable.
(ざっくり訳)
Node.jsが見つかりませんでした。これにより、エディタに主要な機能がなくなります。Node.jsがインストールされPATHにが通っていることを確認してください。

対応1 : 見なかったことにする

  • 環境
    • Windows10 64bit バージョン1909
    • Eclipse IDE for Enterprise Java Developers Version: 2020-03 (4.15.0)

エディタの何かが使えなくなったらしいが、特に困ってないしNode.jsを使う開発でないし面倒くさいし・・・困ったときにインストールする

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

  • 環境
    • CentOS Linux release 7.8.2003 (Core)
    • Eclipse IDE for Enterprise Java Developers. Version: 2020-03 (4.15.0)

NodeSourceのGitHubのReadmeに書いてあるV10~13のいずれかのバージョンをインストールする

# リポジトリを追加する
$ curl -sL https://rpm.nodesource.com/setup_14.x | sudo bash -
...省略...
## Run `sudo yum install -y nodejs` to install Node.js 14.x and npm.
## You may also need development tools to build native addons:
     sudo yum install gcc-c++ make
## To install the Yarn package manager, run:
     curl -sL https://dl.yarnpkg.com/rpm/yarn.repo | sudo tee /etc/yum.repos.d/yarn.repo
     sudo yum install yarn

# コマンドの指示に従ってyumでインストールする
$ sudo yum install -y nodejs
...省略...
Installed:
  nodejs.x86_64 2:14.7.0-1nodesource                                                                                                                                                                               

Complete!

# ちゃんとPATHも通ってめでたしめでたし
$ node -v
v14.7.0

事象2 : Node.js v14.7.0 is not supported.

image.png

原因 : インストールしたNode.jsのバージョンがサポート対象じゃないから

対応 : 見なかったことにする

面倒くさいからそのうち対応するけど今は見なかったことにする

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-08-01T17:44:51+09:00

ローカルで開発中のnuxtプロジェクトをdockerコンテナ（別フォルダ）でnuxt startで公開する方法

ローカルのnuxt開発環境をサクッとdockerで公開したい

全然サクッと公開できなかった・・・

開発環境で色々作っているnuxtのプロジェクト、普段はyarn devやnpm run devで開発・確認をしていますが、お客サンからの一言「どっかサーバーに上げて見れるようにしてくれない？」と。

ここで考えられる対応方法はいくつかあります。

・ビルドしてdist/ フォルダをS3やgithub経由でnetlifyとかにアップする。
　簡単。S3やgithub,netlifyの設定が必要。
　変更のたびにビルド→再アップが必要。

・開発サーバーを放置していいなら、直接 yarn serve(nuxt start)する
　一番簡単、ただしnuxt startをデーモンとして動かないので、サービス化するのに一手間必要。

・dockerコンテナをawsのec2上などに展開する。
　サービス化できるので放置できる。gitと連携しておけば、ファイル更新があってもpullしてコンテナ内で再ビルドできる。

楽なのは、ビルド済みのファイルをS3やnetlifyなどの静的ファイル公開サービスへデプロイする方法です。
ただ、今回セキュリティの事情で、ec2上に乗せる必要がありました。

dockerでnuxtプロジェクトを公開する方法は主に2つありまして

・nginxコンテナでdistフォルダを公開する（一般的）
　本番系に近い方法、SPAの設定が必要。
　https://ja.nuxtjs.org/faq/nginx-proxy/

　こちらも、ソース変更のたびに再ビルドが必要です。

・nodeコンテナで直接 yarn serve（旧 yarn start）する。
　↑今回やる方法

今回、nodeコンテナで公開する方法を使ってみました。
dockerを配置するフォルダと、nuxtのフォルダが別の場所にある場合はひと工夫必要でした。

docker-compose

docker-compose.yml
services:
  node:
    tty: true
    build: ./dockerFileのあるディレクトリ
    volumes:
      - ../../nuxtプロジェクトのフォルダ:/app:delegated
    ports:
      - "80:3000"
    command: ash -c "yarn && yarn build&& yarn export && yarn serve"

Docker-file

FROM node:current as node

WORKDIR /app

ENV NUXT_TELEMETRY_DISABLED 1
ENV HOST 0.0.0.0
ENV PORT 3000

ENV NUXT_TELEMETRY_DISABLED 1が無いと、build時に止まってしまう

https://stackoverflow.com/questions/63096652/how-to-ignore-the-nuxt-js-starting-question

ハマったポイント

docker-composeのvolumesフォルダは、ビルド中には見ることができない。。。
COPYコマンドで親ファイルからソースを持ってくることができない・・・
なので、コンテナを起動してからyarn install,build系のコマンドを叩くようにする必要がありました。

https://crieit.net/posts/docker-build-volume
https://qiita.com/mk-tool/items/1c7e4929055bb3b7aeda
https://qiita.com/katoosky/items/bd24905bca20afdfe745

参考資料

https://jp.vuejs.org/v2/cookbook/dockerize-vuejs-app.html
https://qiita.com/art_porokyu/items/8363334c358c67adb61a
https://qiita.com/tmiyajima/items/b099fb707bfde9337a70

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-08-01T14:39:39+09:00

nodenvでディレクトリごとにバージョンを指定する方法

今回はnodenvのセットアップ方法について簡単に紹介します。
先日、nodebrewのセットアップ方法について紹介したのですが、プロジェクト毎にnode.jsのバージョンを指定したかったのでnodenvに乗り換えました。

はじめに

まず、node.jsのバージョン管理でnodebrewを使用していた場合にはnodebrewを削除する必要があります。
実際の手順を紹介します

使用しているnode.jsのバージョンを控える

その前に現在使用しているnode.jsのバージョンを控えておきましょう。
以下のコマンドの実行結果を控えます。
$ nodebrew list

nodebrewを削除

$ brew uninstall nodebrew

設定ファイルの記述を削除

最後に利用しているシェルの設定ファイルから以下を削除します。
export PATH=$HOME/.nodebrew/current/bin:$PATH

この際、MacOSのバージョンによって設定ファイルが異なりますので注意しましょう。

Catalina以前の場合

vi ~/.bash_profile

Catalinaの場合

vi ~/ .zprofile

こちらに関してはMacOS Cataliaからデフォルトログインシェルが「bash」から「zsh」に変更されたことが理由です。

nodenvインストール

インストールは以下のコマンドで実行できます。
$ brew install nodenv

インストールが完了したら一応確認してみましょう。
$ nodenv -v

バージョンが表示されたらOKです。

設定ファイルの記述

設定ファイルに以下を書き込みます。
export PATH="$HOME/.ndenv/bin:$PATH"
eval "$(ndenv init -)"

ここでも先ほどの注意点と同様に書き込み先を間違えないようにしましょう。

これでnodenvを使用する準備は整いました。

nodenvの使い方

最後にnodenvでのnodeのインストール方法やバージョン指定の方法について簡単に紹介します。

利用できるバージョンの確認

$ nodenv install --list

バージョンを指定してインストール

$ nodenv install <version>

例 : v12.0.0をインストールするとき
$ nodenv install 12.0.0

バージョンの指定

$ nodenv global <version>

ディレクトリ毎にバージョン指定

$ nodenv local <version>

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-08-01T09:28:34+09:00

node.jsの標準のhttpsモジュールでAPIへのリクエストを実行する

やりたいこと

node.jsの標準のhttpsモジュールでAPIへのリクエストを実行したい。
node.jsでHTTPリクエストを行う際には、requestモジュールが使われるケースが多かったようだが、2020/2/11でdeprecatedになったようなので、代わりにnode.jsの標準モジュールで実行したい。

実装

以下のような実装でリクエストを実行できた。
APIは、zipcloud 郵便番号APIを試しに叩いている。

const https = require('https'); // 1: 標準のhttpsモジュールを使用

https.get('https://zipcloud.ibsnet.co.jp/api/search?zipcode=1000000', (res) => {
    if (res.statusCode !== 200) { // 2: status codeが200以外の場合はエラーとする
        console.error("failed to get data. status code: %d", res.statusCode);
        return;
    }

    let rawData = '';
    res.on('data', (chunk) => { // 3: res.on('data', callback関数) で、responseのbodyデータをストリーム形式で処理してくれる。ここではchunkという変数にstreamデータを追加式に格納している。
        rawData += chunk;
    });
    res.on('end', () => { // 4: res.on('end', callback関数) で、responseのbodyデータを読み終わった後の処理を定義。
        try {
            const parsedData = JSON.parse(rawData); // 5. 今回はレスポンスデータがjson形式なのでJSON.parseして、それをログ出力している
            console.log(parsedData) ;
        } catch (e) {
            console.error(e.message);
        }
    });

}).on('error', (e) => {
    console.error(e)
});

コードの説明

1. 標準のhttpsモジュールを使用

標準のhttpsモジュールをrequireしています

2: status codeが200以外の場合はエラーとする

一応、status code（res.statusCode）が200以外の場合はエラー扱いしてログを出力しています。

3: res.on('data', callback関数) で、responseのbodyデータを処理

res.on('data', callback関数) で、responseのbodyデータを処理できます。bodyデータはストリームデータの形式でcallback変数の引数（ここではchunk）に細切れで渡されてくるため、事前に用意しておいた結果格納用変数（rawData）に、細切れごと（ループ内の1回処理ごと）に追加で格納していくという処理を行っています。
node.jsのストリームデータに関しては、こちらのブログ記事やQiitaここちらの記事などが参考になります。

4: res.on('end', callback関数) で、responseのbodyデータを読み終わった後の処理を定義

res.on('end', callback関数) で、responseのbodyデータを読み終わった後の処理を定義できます。

5. 今回はレスポンスデータがjson形式なのでJSON.parseして、それをログ出力している

今回はレスポンスデータがjson形式なのでJSON.parseして、単純にそれをログ出力しています。

実行結果

上記のファイルをindex.jsという名前で保存して、nodeコマンドで実行する。
APIの実行結果が出力される。

$ node index.js
{
  message: null,
  results: [
    {
      address1: '東京都',
      address2: '千代田区',
      address3: '',
      kana1: 'ﾄｳｷｮｳﾄ',
      kana2: 'ﾁﾖﾀﾞｸ',
      kana3: '',
      prefcode: '13',
      zipcode: '1000000'
    }
  ],
  status: 200
}

感想

標準のhttpsモジュールを使用した場合、responseのbodyデータを処理する際に、わざわざstreamデータを取り出す処理を実装しないといけないのが少し面倒だと思った。
requestモジュールなサードパーティのモジュールどを使うと、この辺の処理はモジュール内で良い感じで処理してくれていて呼び出し側では意識する必要がないのは良い。
とはいえ、それ以外はそれほど複雑な実装は必要ないので、上記のような処理を定形処理として覚えてしまっておけば、（わざわざ追加のモジュールを入れずに）標準モジュールだけでサクッとHTTP requestを実装できて便利そう。

参考

公式サイトに記載のサンプルコードを参考にしました。

node.js公式 httpsモジュールのgetメソッドの解説
node.js公式 httpモジュールのgetメソッドの解説　※httpsモジュールのhttp（非SSL）版

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-08-01T07:04:14+09:00

【npm】package, scriptsを利用した開発の際の知見や心得

概要

  • JavaScriptでの開発において、npmを利用して得た知見や心得等のまとめ。
  • 今回は、packageやscriptsに絞って記載。

package

package.json内の情報はできるだけ記述する

  • こちらのメタ情報によって、Documentにもなりえる他、特定環境指定等、より多くの機能を与えることができるため。
  • 例として下記のように指定することで、環境を制限して開発環境を統一することができる。
{
  "engines": {
    "node": ">=10",
    "npm": "~5.0.0"
  }
}

package.json内へのコメントは、フィールドを利用する

  • JSON形式でありコメントの対応が無いため、記述する場合は下記のようにフィールドを利用する形で情報を与える。
    • commentと記述しておくことで、検索が容易。
"comment": "...."

ロックファイルは常にリポジトリにコミットする

  • package-lock.jsonやyarn.lock等のロックファイルは、リポジトリにコミットする必要がある。
  • 理由として、全開発者間で同一のバージョンと依存関係を維持するため。

本番環境へはnpm ciで行う

  • 本番へのデプロイの際には、npm ciコマンドでインストールを行う。
  • 理由として、lockファイルに適した依存関係のクリーンインストールを行い、正確なバージョンを利用する必要があるため。

依存関係を適切かつ最新のものに保つ

  • 脆弱性を防ぎ安全に保つため、常に依存関係を確認する。
  • 下記のような手動・自動ツールを利用して、早期に調整する。
    • npm-check-updates : 依存関係の確認・更新ツール
    • npm-audit: 依存関係の自動修正コマンド。npm v6以上に内包。
    • Dependabot : 脆弱性チェックの自動化ツール。無料。Github社。
    • Snyk : 脆弱性チェックの自動化ツール。有料。

scripts

クロスプラットフォームを意識する

  • 自身の環境だけではなく、「Windows,Linux,MacOS」で利用できるスクリプトを作成する。
    • scripts内でのrm等のUNIXコマンド利用は、Windowsでは対応が難しいため。
  • UNIXコマンドを利用したスクリプトを作成する場合、下記のようなパッケージを利用する。
    • 削除系(rm) : rimraf
    • コピー系(cp) : cpx
    • 汎用系 : shx
  • 下記、記述例
"scripts": {
  "remove": "rimraf ./dist",
  "copy": "cpx -C public/** dist"
},

複数コマンド実行は可能なものは並列で実行する

  • 複数コマンド実行の場合、可能なものは並列で実行して、終了速度を上げる。
  • 並列実行は、下記のようなパッケージを利用することで容易に可能。

同一コマンドで用途が違う場合、コロンで分ける

  • ビルドや監視等、環境やファイルごとにコマンドを使い分ける場合は、下記のようにコロンをつけて分割してまとめる。
    • ※下記のrun-sコマンドは上記記載のnpm-run-allのショートカット
{
  "scripts": {
    "build"     : "run-s build:sass build:ts",
    "build:sass": "sass input.scss output.css",
    "build:ts"  : "tsc main.ts",
    "watch"     : "run-s watch:sass watch ts",
    "watch:sass": "sass --watch input.scss output.css",
    "watch:ts"  : "tsc -w main.ts"
  }
}
  • 補足として、上記のbuildやwatchコマンドは下記のように簡略化できる。
    • 個人的にはアスタリスクよりも波括弧の方が、明示的かつ柔軟。
{
  "scripts": {
    "build"     : "run-s build:*",
    ...
    "watch"     : "run-s watch:{sass,ts}",
    ...
  }
}

参考

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

日付別

タグ一覧