galife

Node.js + Express でエラーページをカスタマイズする方法

Node.js + Express (ejsテンプレート) の環境において 404エラーページと 500エラーページをカスタムエラーページにする方法をまとめます。大きくは「エラー処理の実装」と「エラーページの実装」の2点を行います。以下ではそれぞれについて詳しく見ていきます。

概要
エラー処理の実装
エラーページの実装

概要

すべてのファイルを列挙しているわけではありませんが、前提となる主要なフォルダおよびファイルについて列挙します。想定は以下のような環境です。

プロジェクト構成

PROJECT_ROOT
├ node_modules
│  └ …
├ public
│  └ …
├ routes
│  └ home.js
├ views
│  ├ home
│  │  └ index.js
│  ├ 404.ejs
│  └ 500.ejs
└ app.js

今回作成するのはエラー処理の実装箇所として app.ja、エラーページの実装として 404.ejs および 500.ejs を作成します。テンプレートエンジンに "ejs" を利用しているので、エラーページの拡張子も "ejs" です。

エラー処理の実装

app.js

var express = require('express');
var fs = require('fs');

// express の実態 Application を生成
var app = express();

// テンプレートエンジンを EJS に設定
app.set('views', './views');
app.set('view engine', 'ejs');

// ルーティング設定
var files = fs.readdirSync('./routes');
for(var file of files){
    app.use('/', require('./routes/' + file));
}

// カスタムエラーページ
app.use(function (request, response, next) {
    // 出力するデータ
    var data = {
        method: request.method,
        protocol: request.protocol,
        version: request.httpVersion,
        url: request.url
    };

    // エラーを返却
    response.status(404);
    if (request.xhr) {
        response.json(data);
    } else {
        response.render('./404', { data: data });
    }
});
app.use(function (error, request, response, next) {
    // 出力するデータ
    var data = {
        method: request.method,
        protocol: request.protocol,
        version: request.httpVersion,
        url: request.url,
        name: error.name,
        message: error.message,
        stack: error.stack
    };

    response.status(500);
    if (request.xhr) {
        response.json(data);
    } else {
        response.render('./500', { data: data });
    }
});

// サーバーをポート 3000 で起動
app.listen(3000);

404エラーも 500エラーも app.use を利用しますが、引数となる関数が異なります。両者に共通するのは app.js の中でできるだけ最後の app.use で記載するようにします。（上記の例だとルーティング設定よりも後に登録する） app.use は上から順に登録および処理がされるので、エラー処理はできるだけ最後に行うよう設定します。

404エラーの場合、 function (request, response, next) の 3引数を持つ関数を引数に与えます。エラーページを返す際、ステータスに 404 を設定して response.render で返却します。

500エラーの場合、 function (error, request, response, next) の 4引数を持つ関数を引数に与えます。最初の引数はエラーオブジェクトで、エラー名やメッセージ、スタックトレースが含まれています。エラーページを返す際、400エラーと同様に、ステータスに 500 を設定して response.render で返却します。

エラーページの実装

ページにあまりひねりはありません…単純に必要な情報を表示しています。ただし、500エラーは開発を想定してエラー名、メッセージ、スタックトレースを出していますが、本番ではこのような情報が出ないようくれぐれも注意してください。

404.ejs

<!DOCTYPE html>
<html lang="ja">
  <head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>404 ERROR</title>
    <link rel="icon" href="/public/images/favicon.ico" />
    <link rel="stylesheet" href="/public/third_party/bootstrap/dist/css/bootstrap.css" />
    <link rel="stylesheet" href="/public/stylesheets/index.css" />
    <script type="text/javascript" src="/public/third_party/jquery/dist/jquery.js" defer></script>
    <script type="text/javascript" src="/public/third_party/bootstrap/dist/js/bootstrap.js" defer></script>
  </head>
  <body>
    <div class="container">
      <h1>404 : Not Found</h1>
      <h2>リクエスト</h2>
      <table class="table table-bordered">
        <tr>
          <th class="col-md-2">request</th>
          <td class="col-md-10">
            <span><%= data.method %></span>
            <span> </span>
            <span><%= data.url %></span>
            <span> </span>
            <span><%= (data.protocol || "").toUpperCase() %>/<%= data.version %></span>
          </td>
        </tr>
      </table>
    </div>
  </body>
</html>

500.ejs

<!DOCTYPE html>
<html lang="ja">
  <head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>500 ERROR</title>
    <link rel="icon" href="/public/images/favicon.ico" />
    <link rel="stylesheet" href="/public/third_party/bootstrap/dist/css/bootstrap.css" />
    <link rel="stylesheet" href="/public/stylesheets/index.css" />
    <script type="text/javascript" src="/public/third_party/jquery/dist/jquery.js" defer></script>
    <script type="text/javascript" src="/public/third_party/bootstrap/dist/js/bootstrap.js" defer></script>
  </head>
  <body>
    <div class="container">
      <h1>500 : Internal Server Error</h1>
      <h2>リクエスト</h2>
      <table class="table table-bordered">
        <tr>
          <th class="col-md-2">request</th>
          <td class="col-md-10">
            <span><%= data.method %></span>
            <span> </span>
            <span><%= data.url %></span>
            <span> </span>
            <span><%= (data.protocol || "").toUpperCase() %>/<%= data.version %></span>
          </td>
        </tr>
      </table>
      <h2>エラー</h2>
      <table class="table table-bordered">
        <tr>
          <th class="col-md-2">name</th>
          <td class="col-md-10"><%= data.name %></td>
        </tr>
        <tr>
          <th>message</th>
          <td><%= data.message %></td>
        </tr>
        <tr>
          <th>stack</th>
          <td><%= data.stack %></td>
        </tr>
      </table>
    </div>
  </body>
</html>

以上が Node.js + Express (ejsテンプレート) でカスタムエラーページを作成する方法です。これでデフォルトのしょぼいページからは脱却できるはハズ！！

Node.js で module を作成および利用する方法

開発をしているとよく使う機能や関数、値などはモジュール化して掃き出しておきたいことがあると思います。 Node.js では module を使うことでそうしたことが実現できます。ここでは、 module の具体的な作成方法と利用方法についてまとめます。

基本的な使い方
サンプルコード
- 複数メソッドのモジュール化
- 単一オブジェクトのモジュール化
[補足] module の読み込み
- 読み込み順
- キャッシュ

基本的な使い方

module の作成

module は 1ファイルとして切り出して作成します。作成したファイルにおいて module.exports にモジュール化したいオブジェクトや関数を設定することで module が作成できます。

module.js

var say = function () {
  console.log('hello');
};
module.exports = say;

module の利用

require でモジュールファイルを指定すると module.exports に設定されたオブジェクトや関数が取り出せます。現在のJavaScriptから見た相対パスを指定します。

program.js

var say = require('./module.js');
say();

サンプルコード

以下ではサンプルコードを見ながら具体的な使い方を見ていきます。といっても「利用するときは require("パス") で呼び出し」「作成するときは exports または module.exports に設定」を行うだけです。

複数メソッドのモジュール化

単純に作成した複数メソッドをモジュール化する例を以下に載せます。複数のオブジェクトやメソッドを１つのモジュールにする場合、 exports のプロパティを増やして追加することで出力ができます。

foo.js

var circle = require("./circle.js");
console.log(`半径 4 の 円の面積 は ${circle.area(4)}`);

circle.js

const PI = Math.PI;

exports.area = function (r) {
    return PI * r * r;
}

exports.circumference = function (r) {
    return 2 * PI * r;
}

この例で var circle = require("./circle.js") すると foo.js で以下のようなコードを実行するのと同じ意味になります。

var circle = {
    "area": function (r) {
        return PI * r * r;
    },
    "circumference": function (r) {
        return 2 * r * PI;
    }
};

単一オブジェクトのモジュール化

単一のメソッドやクラスを出力する場合、 module.exports に対して出力したいメソッドやクラスを設定します。先の例であげた exports に設定しても出力できません。

foo.js

var Square = require("./square.js");
var o = new Squre(2);
console.log(`1辺 が 2 の 正方形の面積 は ${o.area()}`);

square.js

var Square = function (width) {
    this.width = width;
};

Square.prototype.area = function () {
    return this.width * this.width;
};

module.exports = Square;

この例の場合、 foo.js で実行している var Square = require("./square.js") は以下のコードと同等になります。

var Square = function (width) {
    this.width = width;
};

Square.prototype.area = function () {
    return this.width * this.width;
};

[補足] module の読み込み

読み込み順

パス Y にあるモジュールで require(X) を行った場合、以下のような読み込みを行います。

パス Y にあるモジュールで require(X) を実行

X がコアモジュールの場合
1. コアモジュールを返します
2. 終了
X が ./ 、 / 、 ../ で始まる場合
1. LOAD_AS_FILE(Y + X)
2. LOAD_AS_DIRECTORY(Y + X)
LOAD_NODE_MODULES(X, dirname(Y))
"not found" の例外をスロー

LOAD_AS_FILE(X)

X がファイルの場合、 JavaScript テキストとして X を読み込んで終了
X.js がファイルの場合、 JavaScript テキストとして X.js を読み込んで終了
X.json がファイルの場合、 JavaScript オブジェクトとして X.json を読み込んで終了
X.node がファイルの場合、バイナリアドオンとして X.node を読み込んで終了

LOAD_AS_DIRECTORY(X)

X/package.json がファイルの場合
1. X/parse.json をパースし、mainフィールドの値を確認
2. LOAD_AS_FILE( X/mainフィールドに指定されたファイル )
X/index.js がファイルの場合、X/index.js を JavaScript として読み込んで終了
X/index.json がファイルの場合、X/index.json を JavaScript として読み込んで終了
X/index.node がファイルの場合、X/index.node を JavaScript として読み込んで終了

LOAD_NODE_MODULES(X, START)

let DIRS = NODE_MODULES_PATHS(START)
for each DIR in DIRS
1. LOAD_AS_FILE( DIR/X )
2. LOAD_AS_DIRECTORY( DIR/X )

NODE_MODULES_PATHS(START)

let PARTS = path split(START)
let I = count of PARTS - 1
let DIRS = []
while I >= 0,
1. PARTS[I] が "node_modules" の場合、CONTINUE
2. DIR = path join(PARTS[0 .. I] + "node_modules")
3. DIRS = DIRS + DIR
4. let I = I - 1
return DIRS

キャッシュ

一度読み込まれたモジュールファイルはキャッシュされます。複数回同じモジュールファイルを読み込もうとしても最初に読み込んだファイルのキャッシュを利用するので複数回読み込むことはありません。

参考記事

package.json の仕様 (日本語)

（この記事は package.json - Specifics of npm's package.json handling をベースに作成しています。 package.json を作成する際、その書き方の参考になればと思います。）

このドキュメントは pakage.json に何を書くべきかについて記載しています。 package.json は単に JavaScript オブジェクトリテラルであるだけでなく JSON でなければなりません。

このドキュメントに記載した動作の多くは npm-config に記載された設定の影響を受けます。

{
  "name": "blue-leaf",
  "description": "Physics-like animations for pretty particles",
  "main": [
    "js/motion.js",
    "sass/motion.scss"
  ],
  "dependencies": {
    "get-size": "~1.2.2",
    "eventEmitter": "~4.2.11"
  },
  "devDependencies": {
    "qunit": "~1.16.0"
  },
  "moduleType": [
    "amd",
    "globals",
    "node"
  ],
  "keywords": [
    "motion",
    "physics",
    "particles"
  ],
  "authors": [
    "Betty Beta <bbeta@example.com>"
  ],
  "license": "MIT",
  "ignore": [
    "**/.*",
    "node_modules",
    "bower_components",
    "test",
    "tests"
  ],
  "homepage": "http://betty.github.io/blue-leaf/index.html",
  "repository": {
   "type": "git",
    "url": "git://github.com/betty/blue-leaf.git"
  },
  "resolutions": {
    "angular": "1.3.0-beta.16"
  },
  "private": true
}

プロパティ名型説明

name

string

必須

package.json にとって name と version はもっとも重要なフィールドです。これらは必須項目で、これらが指定されていないとパッケージをインストールできません。 name と version の組み合わせでパッケージを一意に特定します。パッケージの変更は version の変更も伴うべきものです。

ルール：

214文字以下でなければなりません。この文字数にはスコープ文字列も含まれます。
ドット . またはアンダースコア _ から始めることはできません。
新しいパッケージ名には大文字を含んではいけません。
nameフィールドは URL、コマンドライン引数、フォルダ名の一部になります。そのため、安全でないURL文字を含められません。

ヒント：

Nodeコアモジュールと同じ名前を使ってはいけません。
"js"や"node"を名前の中に含んではいけません。package.json を記載している時点で js であり、 "engine" フィールドを利用することでエンジンを特定することができます。
nameフィールドは require() の引数に渡されるので、ある程度短くも説明的であるべきです。
使おうとしている名前がすでに使われているかどうか、npmレジストリを調べてみてください。
https://www.npmjs.com/

version

string

必須

version は npm の依存として含まれている node-semver で構文解析可能でなければなりません。

バージョン番号に関する詳細は semver を参照してください。

description string 説明を記載します。作成するパッケージを、npm search でリストする際、探しやすくします。

keywords string[] キーワードを文字配列で記載します。作成するパッケージを、npm search でリストする際、探しやすくします。

homepage

string

プロジェクトホームページへのURL。

注意：

"homepage" は "url"とは異なりませ宇。もし "url" フィールドを設定する場合、レジストリはパッケージが別の場所に移されたのでリダイレクトしようとします。

bugs

object

バグトラッカーへの URL または / かつバグ連絡先となるメールアドレス。これらの値はパッケージ利用者がバグに遭遇したときに役立ちます。

サンプル：

{
  "url": "https://github.com/owner/project/issues",
  "email": "project@hostname.com"
}

"url" と "email" のどちらか片方または両方を指定することができます。もし URL のみを指定する場合、"bugs"フィールドの値は単純文字列で指定できます。

URL が指定されている場合、npm bugs コマンドで使われます。

license

string

パッケージ利用における許諾や制限が分かるよう、ライセンスを記載します。

BSD-2-Clause や MIT といった一般的なライセンスを用いる場合、 SPDXライセンス識別子を指定します。

サンプル：

{
  "license": "BSD-3-Clause"
}

SPDXライセンス識別子はこちらを参照してください。理想的には OSI 承認されたものを利用してください。

複数ライセンスを適用する場合、SPDXライセンス構文に従って記載してください。

サンプル：

{
  "license": "(ISC OR GPL-3.0)"
}

SPDXライセンス識別子を利用せず独自のライセンスを使う場合、以下のような文字列値を指定します。

{
  "license": "SEE LICENSE IN <filename>"
}

filename に指定されるファイルはパッケージのトップレベルに配置してください。

author / conributors

string / object / string[] / object[]

"author" は1人、 "contributors" は複数人です。人を表現するオブジェクトは "name" フィールドとオプションで "url" と "email" を持ちます。

サンプル：

{
  "name": "Barney Rubble",
  "email": "barney@rubble.com",
  "url": "http://barnyrubble.tumblr.com/"
}

これらを短くした単一文字列表現も利用できます。

サンプル：

"Barney Rubble <Barney@rubble.com> (http://barneyrubble.tumblr.com/)"

"email" と "url" のどちらもオプションです。

files

string[]

プロジェクトに含まれるファイルリストを指定します。もしフォルダー名のリストを指定する場合、フォルダーにあるファイルが含まれます。（ただし、他のルールは無視されます）

パッケージのルートディレクトリまたはサブディレクトリに ".npmignore"ファイルを配置することができます。これは ".npmignore" はちょうど ".gitignore" のような動きをします。

以下のファイルは設定に関わらず常に含まれます。

package.json
README
CHANGELOG
LICENSE / LICENCE

以下のファイルは常に無視されます。

.git
CVS
.svn
.hg
.lock-wscript
.wafpickle-N
*.swp
.DS_Store
._*
npm-debug.log

main

string

パッケージのエントリーポイントを指定します。 foo というパッケージを作成して、ユーザーがインストールし、require("foo") を実行すると、 mainモジュールで出力設定されたオブジェクトが返されます。

パッケージフォルダのルートからの相対パスで指定します。

多くのモジュールにおいてメインスクリプトを指定すると考えると分かりやすいです。

bin

object

多くのパッケージにおいて PATH に実行可能なファイルをインストールしたいという場合があります。 npm では簡単に設定できます。

利用するには、コマンド名からローカルファイル名へのマッピング情報を package.json の binフィールドに設定します。インストールするとき、グローバルインストールの場合シンボリックリンクを prefix/bin に、ローカルインストールの場合 ./node_modules/.bin/ に配置します。

例えば myapp を以下のように設定した場合、

"bin": {
  "myapp": "./cli.js"
}

myapp をインストールすると、 cli.js スクリプトへのシンボリックリンクを /usr/local/bin/myapp へ作成します。

もし単一の実行可能ファイルでパッケージ名と同じ名前の場合、単純な文字列で表記することができます。

サンプル（以下の2つは同じです）：

"bin": {
  "name": "my-program",
  "version": "1.2.5",
  "bin": "./path/to/program"
}

"bin": {
  "name": "my-program",
  "version": "1.2.5",
  "bin": {
    "my-program": "./path/to/program"
  }
}

man

string / string[]

man プログラム向けに単一ファイルかファイル名の配列を指定します。

単一ファイルを指定する場合、指定したファイル名に関わらず man <パッケージ名> で呼び出せます。

例えば以下のような設定をした場合、 ./man/doc.1 というファイルは man foo コマンドで呼び出されます。

{
  "name": "foo",
  "version": "1.2.3",
  "description": "A packaged foo fooer for fooing foos",
  "main": "foo.js",
  "man": "./man/doc.1"
}

ファイル名がパッケージ名で始まっていない場合、プレフィックスにパッケージ名が付きます。例えば以下のような設定をした場合、man foo および man foo-bar が作られます。

{
  "name": "foo",
  "version": "1.2.3",
  "description": "A packaged foo fooer for fooing foos",
  "main": "foo.js",
  "man": ["./man/foo.1", "./man/bar.1"]
}

manファイルのファイル名は数値で終わっている必要があります。オプションで、圧縮している場合は .gz サフィックスが付けられます。数値はセクションを示しており、以下のような設定をした場合、 man foo および man 2 foo が作られます。

directories

object

"doc"、"lib"、"man"といったディレクトリがどこにあるかを定義できます。

lib	ライブラリファイル郡がどこにあるかを定義します。
bin	"bin"を定義する場合、すべてのファイルを定義したフォルダ配下に配置します。 "bin"と"directories.bin"の両方を定義するとエラーになります。単一ファイルを定義する場合は"bin"を利用し、存在するすべてのファイルを定義する場合は"directories.bin"を利用します。
man	定義されたディレクトリ配下のデータを元に manページを作成します。 "man"へのショートカットになります。
doc	markdownファイルを配置します。いつかどこかでうまく表示できるようになるハズ…。
example	サンプルスクリプトを配置します。いつかどこかでうまく表示できるようになるハズ…。

例えば以下のような設定を記述します。

{
   "lib": "src/lib",
   "bin": "local/binaries",
   "doc": "doc" 
}

repository

object / string

コードがどこにあるかを定義します。コード修正に参加したいと思った人にとって有用な情報になります。 GitHub上にリポジトリがあれば npm docs コマンドで参照できます。

"repository": {
  "type" : "git",
  "url" : "https://github.com/npm/npm.git"
}

"repository": {
  "type" : "svn",
  "url" : "https://v8.googlecode.com/svn/trunk/"
}

URLは一般に公開されたURLを使用します。また、htmlページではなく機械が読み取れるURLを指定します。

GitHub、GitHub gist、Bitbucket、GitLabリポジトリを利用する場合、ショートハンドが利用できます。

"repository": "npm/npm"

"repository": "gist:11081aaa281"

"repository": "bitbucket:example/repo"

"repository": "gitlab:another/repo"

scripts

object

パッケージのライフサイクル中における様々なシーンで呼び出されるコマンドを定義します。キーはライフサイクル中のイベント名で、値はコマンド実行されたときに実行するスクリプトを定義します。

以下は "install" および "uninstall" コマンドを定義するサンプルです。

"scripts" : {
  "install" : "scripts/install.js",
  "uninstall" : "scripts/uninstall.js"
}

config

object

config オブジェクトではパッケージスクリプトで利用する設定値を指定できます。例えば以下のような設定を行った場合、

{
  "name" : "foo",
  "config" : {
    "port" : "8080"
  }
}

npm_package_config_port という環境変数が設定されます。この値は npm config set foo:port 8001 のように実行することで上書きすることもできます。

dependencies

object

dependencies は単純なオブジェクトでパッケージ名とバージョン範囲を指定します。バージョン範囲は1つ以上のスペース区切り文字列を指定します。 dependencies には tarball や git の URL を指定することもできます。

テスト用の依存ファイルは指定しないでください。以下の devDependencies を参照してください。

バージョン番号に関する詳細は semver を参照してください。

version	指定されたバージョンのみ
>version	指定されたバージョンより新しいバージョン
>=version	指定されたバージョン以降の新しいバージョン
<version	指定されたバージョンより古いバージョン
<=version	指定されたバージョン以前の古いバージョン
~version	ほぼ類似するバージョン。パッチバージョンレベルで更新されたもの。詳細は semver を参照してください。
^version	互換性のあるバージョン。メジャーバージョンが更新されないレベルのもの。詳細は semver を参照してください。
1.2.x	1.2.0, 1.2.1, ... 。1.3.0はNG。
http://...	以下の URL を参照してください。
*	どのようなバージョンでも許可。
""(空文字)	* と同じ。
version1 - version2	`>=version1 <=version2` と同じ
range1 \|\| range2	range1 または range2 を満たす場合を許可
git...	以下の Git URL を参照してください。
user/repo	以下の GitHub を参照してください。
tag	`npm-tab` で指定されたタグを指定
path/path/path	以下のローカルバスを参照してください。

サンプルは以下のようになります。

"dependencies" : {
  "foo" : "1.0.0 - 2.9999.9999",
  "bar" : ">=1.0.2 <2.1.2",
  "baz" : ">1.0.2 <=2.3.4",
  "boo" : "2.0.1",
  "qux" : "<1.0.0 || >=2.3.1 <2.4.5 || >=2.5.2 <3.0.0",
  "asd" : "http://asdf.com/asdf.tar.gz",
  "til" : "~1.2",
  "elf" : "~1.2.3",
  "two" : "2.x",
  "thr" : "3.3.x",
  "lat" : "latest",
  "dyl" : "file:../dyl"
}

URL

tarball への URL を指定します。指定された tarball はインストール時にダウンロードされます。

Git URL

Git URL は以下のように指定します。

git://github.com/user/project.git#commit-ish
git+ssh://user@hostname:project.git#commit-ish
git+ssh://user@hostname/project.git#commit-ish
git+http://user@hostname/project/blah.git#commit-ish
git+https://user@hostname/project/blah.git#commit-ish

commit-ish には git checkout の引数で利用するタグ、sha、ブランチを指定できます。デフォルトは master です。

GitHub URL

バージョン 1.1.65 以降では、"foo" : "user/foo-project" のように指定できます。 Git URL のように commit-ish サフィックスをふくめることもできます。

{
  "name": "foo",
  "version": "0.0.0",
  "dependencies": {
    "express": "visionmedia/express",
    "mocha": "visionmedia/mocha#4727d357ea"
  }
}

ローカルパス

バージョン 2.0.0 以降では、パッケージに含んでいるローカルディレクトリのパスを指定できます。ローカルパスは npm install -S または npm install --save で保存できます。保存する際は相対パスで package.json に保存されます。

{
  "name": "baz",
  "dependencies": {
    "bar": "file:../foo/bar"
  }
}

この機能は外部サーバーへアクセスしたくない、ローカルオフライン開発やテスト実施においてnpmインストールが必要な時に便利です。ただし、パッケージを一般公開する際は使わないようにしてください。

devDependencies

object

公開されたパッケージを利用する際、テストフレームワークやドキュメントフレームワークといったものはダウンロードする必要がありません。こうした場合、一番良いのはこれらを devDependencies に指定することです。

ここで指定したパッケージはパッケージルートで npm link または npm install を実行するとインストールされ、他のパラメータと同様に管理されます。詳しくは npm-config を参照してください。

CoffeeScriptといったプラットフォーム固有でないビルドイベントは、devDependencies でパッケージ依存を指定して prepublish スクリプトを使うことで実現します。

サンプル：

{
  "name": "ethopia-waza",
  "description": "a delightfully fruity coffee varietal",
  "version": "1.2.3",
  "devDependencies": {
    "coffee-script": "~1.6.3"
  },
  "scripts": {
    "prepublish": "coffee -o lib/ -c src/waza.coffee"
  },
  "main": "lib/waza.js"
}

prepublishスクリプトは公開前に実行されます。そのため、ユーザーはコンパイルを気にすることなく機能を利用することができます。開発モード（例えば、ローカルで npm install を実行する場合）、このスクリプトはうまく動作するため、簡単にテストができます。

peerDependencies

object

場合により、ホストツールやライブラリとの互換性のため、必ずしも必要ではないパッケージがあるかもしれません。これは一般にプラグインと呼ばれるものです。特に、ホストドキュメントによって期待されるまたは指定される、特定のインターフェースを公開しているかもしれません。

サンプル：

{
  "name": "tea-latte",
  "version": "1.3.5",
  "peerDependencies": {
    "tea": "2.x"
  }
}

あなたのパッケージ tea-latte をインストールすることができるのはホストパッケージである tea がバージョン 2.x の場合のみとすることができます。 npm install tea-latte は以下の依存グラフの場合だけ実行できます。

├── tea-latte@1.3.5
└── tea@2.2.0

注意： npm のバージョンが 1 または 2 の場合、peerDependencies で指定されたバージョンより高ければ自動的にインストールを行います。次のバージョン (バージョン 3) ではこのようなことが起こらなくなり、代わりに警告が表示されるようになります。 npm 1 と 2 のこの動作は頻繁に混乱を起こし依存地獄に陥れていましたが、できるだけ避けられるようにデザインされます。

他のプラグインをインストールしようとしたとき依存エラーを起こすことがあります。この原因は、あなたのプラグインが要求する依存バージョンがパッチバージョンまで指定してしまっているためです。

ホストコンパイルを考えたとき、ホストパッケージのメジャーバージョンの変更のみがあなたのプラグインを壊します。ですから、もしあなたがすべてのホストパッケージをバージョン 1.x で動作させたいなら、 ^1.0 または 1.x を指定します。もし 1.5.2 で出てきた機能に依存しているのであれば >=1.5.2 <2 を指定します。

bundledDependencies

string[]

パッケージ公開するときバンドルするパッケージの配列を指定します。

bundleDependencies の綴りでも動作します。

optionalDepencencies

object

dependency を利用するがインストール時に失敗とさせたくない場合、 optionalDependencies を利用します。これはパッケージ名とバージョンまたはURLのマップブジェクトで、dependencies に似ています。違いはインストール時のエラーを発生させない点です。

インストールは行われるので、依存関係が欠損している部分をプログラムで処理s手あげる必要があります。以下にサンプルコードを記載します。

try {
  var foo = require('foo')
  var fooVersion = require('foo/package.json').version
} catch (er) {
  foo = null
}
if ( notGoodFooVersion(fooVersion) ) {
  foo = null
}

// .. then later in your program ..

if (foo) {
  foo.doFooThings()
}

optionalDependencies の値は dependencies で上書きされます。

engines

object

動作するnodeバージョンを指定することができます。

"engines" : {
  "node" : ">=0.10.3 <0.12"
}

dependencies と同様に特に指定しないまたは "*" を指定した場合、どのnodeバージョンでも動作します。 engines はどのバージョンで正しく動作するかを指定します。

engine-strict フラグが設定されていなければ、この値は警告を表示するのみの動作になります。

engineStrict

boolean

この機能は npm 3.0.0 で廃止されます。

npm 3.0.0 以降では engine-strict を指定するようにしてください。

string[]

どの OS で動作するかを指定します。

"os": [
  "darwin", "linux"
]

! を使用することでブラックリスト指定もできます。

"os": [
  "!win32"
]

ブラックリストとホワイトリストは両方使えます。

cpu

string[]

ある特定のCPUアーキテクチャで動作する場合、それを指定します。

"cpu": [
  "x64", "ia32"
]

ブラックリストも指定できます。

"cpu": [
  "!arm", "!mips"
]

preferGlobal

boolean

あなたのパッケージがグローバルに利用されるコマンドラインアプリケーションである場合、この値を true にしてローカルインストールされた場合に警告表示するようにします。

private

boolean

"private" : true を設定すると、npm は該当パッケージの公開を拒否します。

これは間違ってプライベートリポジトリが公開されるのを防ぐために使います。もしパッケージを特定のレジストリにのみ公開したい場合は publishConfig を設定して registry 設定を公開するときに上書きする設定を行ってください。

publishConfig

公開時に利用される設定値を指定します。タグ、レジストリ、アクセス先を指定すると、特定のパッケージに "latest" のタグ付けがされていない、グローバルに公開されたレジストリを使う、デフォルトでプライベートなモジュールを見ている、といったものの扱いで便利です。

あらゆる設定が上書き可能ですが、tag 、registry、 access が重要です。

上書き可能なオプションは npm-config を参照してください。

参考記事

npm - package.json : Specifics of npm's package.json handling

npm の使い方

npm の基本的な使い方をまとめておきます。

プロジェクトの初期化
パッケージのインストール
パッケージのアンインストール
インストール済みパッケージの一覧表示
パッケージの更新

プロジェクトの初期化

現在のディレクトリをルートディレクトリとして package.json を作成します。 package.json には今から作ろうとしているプロジェクトで利用するパッケージ情報 (以下のインストールを行った情報) が記載されます。

基本的には質問に答えて入力していくだけで package.json が初期化されます。もし、すでに package.json が存在している場合、記載されているパッケージ情報に従って必要なパッケージをダウンロードおよび配置設定します。

npm init

package.json に依存関係を保存する場合、インストール時に --save オプションを付与して保存します。

パッケージのインストール

パッケージ名 %PACKAGE_NAME% を指定して現在のプロジェクトにパッケージをインストールします。 --save オプションを付けると、 package.json に依存関係情報を書き込みます。

npm install %PACKAGE_NAME%

npm install %PACKAGE_NAME% --global

ローカルインストールとグローバルインストール

パッケージインストール先は「ローカル」と「グローバル」の2種類があります。 --global または -g オプションを付けるかどうかでローカルインストールとグローバルインストールを切り替えられます。それぞれの違いは以下の通りです。

ローカルインストール (`--global` オプションなし)

現在のプロジェクトの依存関係として取り込む ( Node.js の require で使う) 場合はローカルインストールします
インストール先は現在のプロジェクト配下に作られる node_modules フォルダ配下にインストールされます
コマンドとして実行する場合はパスを通して実行する必要があります

グローバルインストール (`--global` オプションあり)

コマンドラインツール (e.g. bower, grunt, jshint) はグローバルインストールします
インストール先はデフォルトなら以下の場所
```
C:\Users\<UserName>\AppData\Roaming\npm\node_modules
```
パスが通っているので実行はコマンドをそのまま叩けば実行できる

パッケージのアンインストール

インストール済みのパッケージを削除します。

npm uninstall %PACKAGE_NAME%

インストール済みパッケージの一覧表示

インストールされているパッケージの一覧を表示します。

npm ls

パッケージの更新

インストールされているパッケージに新しいバージョンがあれば更新を行います。

npm update %PACKAGE_NAME%

よく使うコマンドに絞ってまとめてみました。とりあえずここに記載のコマンドが理解できていれば何とかはなるかと思います。

log4net の使い方

少し今更なのですが…忘れてしまっていて調べなおしを行ったのでメモしておきます。

log4net の基本的な利用方法を手順に従ってまとめてみました。とりあえず利用するには以下の手順に従ってコピペしていけば利用できるはずです。

1. log4net をプロジェクトに組み込み

以前はアセンブリをダウンロードしてきて参照設定して…とありましたが、現在は NuGet から取得可能です。

プロジェクトを右クリック、「NuGetパッケージの管理」を選択
検索窓に「log4net」を入力
検索結果の log4net の「インストール」を選択
ソリューションエクスプローラーで参照設定に「log4net」があることを確認

2. AssemblyInfo.cs へ追記

log4net の設定ファイルがどこにあるかを記載します。ここでは log4net.config というファイル名にしてあります。また、 Watch を指定することで、設定ファイルに変更があった場合に動的に読み込みを行ってくれるようになります。

AssemblyInfo.cs

// log4net configuration file
[assembly: log4net.Config.XmlConfigurator(ConfigFile=@"log4net.config", Watch=true)]

3. log4net.config の作成

プロジェクトルートに log4net.config ファイルを追加します。追加した log4net.config はリリース時にコピーされる必要があるので、「出力ディレクトリにコピー」を「常にコピー」に設定しておきます。

以下では追加した log4net.config に log4net の設定を定義します。サンプルなので一定サイズごとにファイル分割を行うログ出力を行える設定にしてあります。

log4net.config

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <log4net>

    <appender name="RollingLogFileAppender" type="log4net.Appender.RollingFileAppender">
      <file value="application.log" />
      <appendToFile value="true" />
      <rollingStyle value="Size" />
      <maxSizeRollBackups value="10" />
      <maximumFileSize value="1MB" />
      <layout type="log4net.Layout.PatternLayout">
        <conversionPattern value="%d{yyyy-MM-ddTHH:mm:ss} [%-5level] - %message%newline" />
      </layout>
    </appender>

    <root>
      <level value="ERROR" />
      <appender-ref ref="RollingLogFileAppender" />
    </root>

  </log4net>
</configuration>

4. ログ出力の実装

ログ出力は LogManager.GetLogger() で ILog を取得して利用します。

    public static void Main(params string args)
    {
        // ロガーの取得
        // (補足)log4net.config の appender@name に
        //       引数で渡した名前の appender は存在しないので root が取得される
        var logger = LogManager.GetLogger(Assembly.GetExecutingAssembly().FullName);

        // ログ出力
        logger.Debug("デバッグ：処理の中間情報");
        logger.Info("情報：操作履歴");
        logger.Warn("注意：現在は正常に動作が続けられるがデータ不整合の可能性がある操作。");
        logger.Error("エラー：復旧可能な障害。継続できるが処理はロールバックされる。");
        logger.Fatal("障害：アプリケーションが強制終了する障害");
    }

簡単にですが…メモ程度に log4net の使い方をまとめておきました。これでまた調べることは無くなるはず！

C# で string と MemoryStream を変換する方法

Web通信やファイル操作を行う際、文字列(String) とメモリ配列(MemoryStream) を交換が発生します。今回はそれぞれを相互へんかんする方法をまとめました。

まぁ、実際には「まとめ」に記載しているサンプルコードをコピペして利用すればラクだと思います。

String → MemoryStream 変換
MemoryStream → String 変換
まとめ

String → MemoryStream 変換

using System.IO;
using System.Text;

class Class1
{
    public MemoryStream GetMemoryStream(string text)
    {
        return new MemoryStream(Encoding.UTF8.GetBytes(text));
    }
}

MemoryStream → String 変換

using System.IO;
using System.Text;

class Class1
{
    public string GetString(MemoryStream stream)
    {
        return Encoding.UTF8.GetString(stream.ToArray());
    }
}

まとめ

文字列⇔メモリストリームの相互変換は拡張メソッドに定義しました。以下のファイルをプロジェクトに組み込めば簡単に相互変換を利用できます。

メモリストリーム→文字列の変換メソッド名が ToString でデフォルトと被っている点がいまいちですが… いい名前が思いつかずこのままにしています。利用する際は Encoding の指定をお忘れなく…。

ConverterExtensions.cs

using System.IO;
using System.Text;

namespace Sample
{
    /// <summary>
    /// 文字列とメモリストリームの相互変換拡張メソッドを提供します。
    /// </summary>
    public static class ConverterExtensions
    {
        /// <summary>
        /// 文字エンコーディングを指定して現在の文字列を表すメモリストリームを取得します。
        /// </summary>
        /// <param name="text">現在の文字列</param>
        /// <param name="encoding">文字エンコーディング</param>
        /// <returns>メモリストリーム</returns>
        public static MemoryStream ToMemoryStream(this string text, Encoding encoding)
        {
            return new MemoryStream(encoding.GetBytes(text));
        }

        /// <summary>
        /// 文字エンコーディングを指定して現在のメモリストリームを表す文字列を取得します。
        /// </summary>
        /// <param name="stream">メモリストリーム</param>
        /// <param name="encoding">文字エンコーディング</param>
        /// <returns>文字列</returns>
        public static string ToString(this MemoryStream stream, Encoding encoding)
        {
            return encoding.GetString(stream.ToArray());
        }
    }
}

使い方

using Sample;

public class Class1
{
    public void ConvertFromStringToMemoryStream()
    {
        var stream = new MemoryStream();
        var text = stream.ToString(Encoding.UTF8);
    }

    public void ConvertFromMemoryStreamToString()
    {
        var text = "なにか文字列";
        text.ToMemoryStream(Encoding.UTF8);
    }
}

C# の DataGridView でソートを無効化する方法

DataGridView ネタが続いています。。今回は DataGridView でソートを無効化する方法。といっても方法は簡単で、 DataGridView のカラムに対して NotSortable を設定するだけです。具体的な方法は以下で見ていきます。

デザイナで設定する
コードで設定する

デザイナで設定する

以下では Visual Studio のデザイナから修正を行います。デザイナから修正するとコードが隠れるので、ソート無効化したいカラムが確定しているならこの方法が良いと思います。

ソート無効化したい DataGridView のタスクを開きます。
「列の編集」を選択します。
ソート無効化したいカラムの SortMode を NotSortable にします。

コードで設定する

行うことは上記のGUI設定と同じです。動的に変更したいという要望がない限り、GUIで設定した方がコードが隠れて良い気がします。

以下のサンプルコードではすべてのカラムでソートを無効化しています。

public partial class Form1 : Form
{
    public Form1()
    {
        this.InitializeComponent();

        // dataGridView1 の すべてのカラムで ソート を 無効化
        foreach (DataGridViewColumn column in this.dataGridView1.Columns)
        {
            column.SortMode = DataGridViewColumnSortMode.NotSortable;
        }
    }
}

これまにで DataGridView をいくつか記事にしてきましたが、とりあえず今回まででひと段落です。これまでの記事と組み合わせれば DataGridView はきっとうまく使いこなせるようになっているハズ！

C# & JavaScript

概要

エラー処理 の 実装

エラーページ の 実装

基本的な使い方

module の 作成

module の 利用

サンプルコード

複数メソッドのモジュール化

単一オブジェクトのモジュール化

[補足] module の 読み込み

読み込み順

キャッシュ

プロジェクト の 初期化

パッケージ の インストール

ローカルインストール と グローバルインストール

ローカルインストール (--global オプションなし)

グローバルインストール (--global オプションあり)

パッケージ の アンインストール

インストール済み パッケージ の 一覧表示

パッケージ の 更新

概要

1. log4net を プロジェクト に組み込み

2. AssemblyInfo.cs へ追記

3. log4net.config の作成

4. ログ出力の実装

String → MemoryStream 変換

MemoryStream → String 変換

まとめ

デザイナ で 設定する

コード で 設定する

エラー処理の実装

エラーページの実装

module の作成

module の利用

[補足] module の読み込み

プロジェクトの初期化

パッケージのインストール

ローカルインストールとグローバルインストール

ローカルインストール (`--global` オプションなし)

グローバルインストール (`--global` オプションあり)

パッケージのアンインストール

インストール済みパッケージの一覧表示

パッケージの更新

1. log4net をプロジェクトに組み込み

デザイナで設定する

コードで設定する