Node.jsのモジュール機能について



Node.jsのモジュール機能について学習した。
モジュール機能は、サーバーサイドJavaScriptの標準APIの仕様を定めるプロジェクトであるCommonJSでも、早い時期から規格化と実装が進んでいたようだ。
モジュールは、プログラムのソース・ファイルを複数ファイルに分けて管理し、名前空間を分離することを可能にする、Node.js自体が提供する言語機能である。

Nodeのバージョンは、

$ node -v

v10.9.0

モジュールのエクスポートとインポート

下記の構成で、2つのファイルを使って検証した。

$ pwd

/Users/user/Desktop/node_test
$ ls 

Animal.js main.js

まずは、モジュールとして利用される側。
moduleという名前のオブジェクトが、最初から存在する。
moduleオブジェクトのexportsプロパティが参照するオブジェクトのプロパティに、エクスポートするオブジェクトを設定することで、オブジェクトをエクスポートできる。

Animal.js
var Animal = function() {}
module.exports.Animal = Animal;

モジュールとして利用する側は、require関数を使う。
require関数の引数には、ファイル名を指定する。ファイル名の.jsは省略できる。

main.js
var lib = require('./Animal')
var animal = new lib.Animal();

当然下記のようにも書ける。

var Animal = require('./Animal').Animal;
var animal = new Animal();

実行すると、特にエラーなく処理が終了する。


$ node main.js 


モジュールは、デフォルトでグローバルの名前空間を汚染しない。

下記のように、エクスポートしない場合は、別のファイルから見えない。

Animal.js
var Animal = function() {}
// module.exports.Animal = Animal;

$ node main.js
TypeError: lib.Animal is not a constructor

module以外に、exportsという名前のオブジェクトも、最初から存在する。
下記のコードでtrueが出力されることが示すように、module.exportsとexportsは、同じオブジェクトを参照している。

console.log(module.exports === exports)

従って、下記のようにも書ける。

Animal.js
exports.Animal = Animal;


moduleオブジェクト

console.debugで、moduleオブジェクトについて、詳しく見てみた。


Animal.js
var Animal = function() {}
module.exports.Animal = Animal;
console.debug(module)

$ node main.js
Module {
  id: '/Users/user/Desktop/node_test/Animal.js',
  exports: { Animal: [Function: Animal] },
  parent:
   Module {
     id: '.',
     exports: {},
     parent: null,
     filename: '/Users/user/Desktop/node_test/main.js',
     loaded: false,
     children: [ [Circular] ],
     paths:
      [ '/Users/user/Desktop/node_test/node_modules',
        '/Users/user/Desktop/node_modules',
        '/Users/user/node_modules',
        '/Users/node_modules',
        '/node_modules' ] },
  filename: '/Users/user/Desktop/node_test/Animal.js',
  loaded: false,
  children: [],
  paths:
   [ '/Users/user/Desktop/node_test/node_modules',
     '/Users/user/Desktop/node_modules',
     '/Users/user/node_modules',
     '/Users/node_modules',

     '/node_modules' ] }

moduleオブジェクトのプロパティが一覧された。

exportsプロパティの存在が確認できる。

parentプロパティには、モジュールを呼び出している側のmoduleオブジェクトが格納されるようだ。

pathsプロパティには、モジュールを探すパスの配列が設定されているようだ。
基本的に、node_modulesというディレクトリーを親ディレクトリーに向かって探していくようだ。
注目すべきは、pathsプロパティの配列に、カレントディレクトリーが含まれていないことである。
よって、下記のコードはエラーとなる。

var Animal = require('Animal').Animal;

$ node main.js

Error: Cannot find module 'Animal'

下記の構成にすれば、node_modulesはモジュールを探すパスであるため、上記のコードでも問題ない。

.
├── main.js
└── node_modules

    └── Animal.js

require関数

console.debugで、require関数について、詳しく見てみた。

main.js
var Animal = require('Animal').Animal;
var animal = new Animal();
console.debug(require)

$ node main.js
{ [Function: require]
  resolve: { [Function: resolve] paths: [Function: paths] },
  main:
   Module {
     id: '.',
     exports: {},
     parent: null,
     filename: '/Users/user/Desktop/node_test/main.js',
     loaded: false,
     children: [ [Module] ],
     paths:
      [ '/Users/user/Desktop/node_test/node_modules',
        '/Users/user/Desktop/node_modules',
        '/Users/user/node_modules',
        '/Users/node_modules',
        '/node_modules' ] },
  extensions:
   { '.js': [Function], '.json': [Function], '.node': [Function] },
  cache:
   { '/Users/user/Desktop/node_test/main.js':
      Module {
        id: '.',
        exports: {},
        parent: null,
        filename: '/Users/user/Desktop/node_test/main.js',
        loaded: false,
        children: [Array],
        paths: [Array] },
     '/Users/user/Desktop/node_test/node_modules/Animal.js':
      Module {
        id: '/Users/user/Desktop/node_test/node_modules/Animal.js',
        exports: [Object],
        parent: [Module],
        filename: '/Users/user/Desktop/node_test/node_modules/Animal.js',
        loaded: true,
        children: [],

        paths: [Array] } } }

require関数のプロパティが一覧された。

mainプロパティは、メインとして実行されたスクリプトのmoduleオブジェクトが格納されるようだ。
よって、下記のコードは、メインとして実行されたスクリプトではtrueとなる。

main.js
console.debug(require.main === module)

$ node main.js 

true

利用されるモジュール側でも確認すると、確かにrequire.mainには、メインとして実行されたスクリプトであるmain.jsのmoduleオブジェクトが格納されている。

Animal.js
var Animal = function() {}
module.exports.Animal = Animal;
console.debug(require.main === module)
console.debug(require)

$ node main.js
false

{ [Function: require]
  resolve: { [Function: resolve] paths: [Function: paths] },
  main:
   Module {
     id: '.',
     exports: {},
     parent: null,
     filename: '/Users/user/Desktop/node_test/main.js',
     loaded: false,
     children: [ [Module] ],
     paths:
      [ '/Users/user/Desktop/node_test/node_modules',
        '/Users/user/Desktop/node_modules',
        '/Users/user/node_modules',
        '/Users/node_modules',
        '/node_modules' ] },

  extensions:
以下省略...

このように、メインとして実行されたスクリプトを特定できる。




コメント

コメントを投稿

このブログの人気の投稿

PowerShell 6で、Shift_JISのCSVをImport-Csvで読み込んだら文字化けした

Follow @venividivici830 PowerShell 4で作ったShift_JIS（シフトJIS）のCSVを読み込むスクリプトを、PowerShell 6で動かしたら文字化けした話。 結論としては、下記のようにすればOK。 > Import-Csv -Encoding ([System.Text.Encoding]::GetEncoding(932)) path_to_csv_file 現象 PowerShell 4では、 このページ にあるように、Import-Csvコマンドレットのオプションとして、-Encoding defaultを付ければよかった。 ところが、PowerShell 6では上手くいかない。 例えば、下記のようなshift-jisのCSVがある。 名前,年齢 田中,20 山田,10 これを、-Encoding defaultオプションで読み込むと、 > Import-Csv -Encoding default ./test.csv                        O N ---- ---- c 20   Rc 10   このように文字化けする具合だ。 原因 まず、「default」がutf-8に変わったのが原因のようだ。 .NET Framework クラスライブラリーの、System.Text名前空間の、Encodingクラスの、Defaultプロパティーを確認した。 > [ System.Text.Encoding ]:: Default BodyName           : utf-8 EncodingName       : Unicode (UTF-8) HeaderName         : utf-8 WebName           : utf-8 WindowsCodePage   : 1200 IsBrowserDisplay   : True IsBrowserSave     : True IsMailNewsDisplay : True IsMailNewsSave     : Tru
続きを読む

Windowsで、特定のユーザーに特定のサービスの再起動を許可する

Follow @venividivici830 Windowsで、ユーザーごとに、サービスレベルで操作権限（サービスの開始、停止など）を与える話です。 流れとしては、 scコマンドで、サービスの随意アクセス制御リスト (DACL) に対し、セキュリティ記述子定義言語 (SDDL) 構文で、アクセス制御情報を追加する ことになります。 これにより、あるユーザーはOracleの再起動だけ許可、あるユーザーはTomcatの再起動だけ許可、など、細かい権限設定が可能です。 サーバーのマシン自体の再起動権限は与えられないけど、アプリケーションサーバープログラムや、DBサーバープログラムの再起動だけは許可したい、などのシチュエーションに使えます。 サービスのDACLは、名の通り、サービス単位で権限を制御するためのACLです。 SDDLは、ACLを文字列で記述するための構文です。 「;」で各フィールドを区切る形です。詳細については、 こちら 。に公式ドキュメントｇ サービスの操作権限をユーザーレベルで制御するには、最低限、下記のように3つのフィールドを設定すれば良いようです。 (許可 (A)/拒否 (D);;アクセス許可の文字列;;; SID ) ;;や;;;って何だよ、と最初見た時思いましたが、フィールドが空で、デリミター（;）だけが並んでいるだけですね。 許可 (A)/拒否 (D) には、サービスに対する特定の操作を 許可する場合はA、拒否する場合はD を設定します。 （許可または拒否する）サービスに対する特定の操作は、 アクセス許可の文字列 で設定します。 このページ に、 アクセス許可の文字列 に設定できる値が一覧されています。 再起動の場合は、RP(Start)とWP(Stop)の操作を許可すれば良いので、RPWP を指定すれば良いです。 SID は、ユーザーオブジェクトに固有のIDで、要はユーザーのIDです。権限を付与したいユーザーのSIDを指定します。 権限を付与したいユーザーで、 コマンドプロンプトからwhoamiコマンドをuserオプション付きで実行することにより、SIDを取得できます。 > whoami /user WIndowsにもwhoamiコマンドがあったんですね。知らなかった。 まと
続きを読む

PowerShellでイベントログを取得する時、「指定した選択条件に一致するイベントが見つかりませんでした。」が煩わしいのでcatchする

Follow @venividivici830 Windowsサーバーを点検する時など、イベントログをPowerShellで操作すると便利です。 Get-WinEventコマンドレットでイベントログを取得できますが、指定した条件に当てはまるイベントログがない場合、下記のエラーがスローされます。 Get-WinEvent : 指定した選択条件に一致するイベントが見つかりませんでした。 〜 NoMatchingEventsFound, 〜 NoMatchingEventsFoundが示すように、ただ指定した条件にマッチするイベントがなかっただけなので、条件としてエラーのレベルを「重大」や「エラー」にした場合は、特に問題ないことが多い。 エラーとして赤文字でコンソールに出力されるのは煩わしいので、catchする。 下記は、スクリプトの例。 $ErrorActionPreference = "Stop" $today = Get-Date $from = $today.AddMonths(-1) $filter = @{LogName="system"; Level=1; StartTime=$from} try { Get-WinEvent -FilterHashtable $filter } catch { $category = $Global:Error[0].CategoryInfo.Category.ToString() if ($category -eq "ObjectNotFound") { # 問題ない } else { # Error Handling } } 上の例では、過去1ヶ月分の、WIndowsログ→システムの、エラーレベルが「重大」のログを取得している。 下記の部分のsystemを「application」に変えれば、アプリケーションのログを取得できる。 また、Level=2、3とすることで、それぞれエラーレベルが「エラー」、「警告」のログを取得できる。 $filter = @{LogName="system"; Level=1; StartTime
続きを読む