こんにちは、フロントエンドエンジニアのいなばです。
過去に作った小さなライブラリを使い回すことが多くなったので、よく使うものをnpmに公開してみました。公開するための手順を調べたので、備忘録として残しておきたいと思います。
npmアカウントの作成
npmへライブラリを公開するために、まずは https://npmjs.org/signup からアカウントを作成します
- username
- password
- email address
は、あとで使うので忘れないようにしましょう。
ユーザーの登録をする
ターミナルを開いて、下記のコマンドを実行します。
$ npm adduser
先ほど作成したnpmアカウントのusername、password、email addressを聞かれるので入力します。 これで事前の準備は完了です。
公開するライブラリを用意する
今回npmに登録してみたライブラリのリポジトリはこちらになります。
https://github.com/i78s/frontend-utils
今回はnpmに公開して、下記のようにインストールして使えるようになることを目標とします。
$ npm install i78s.frontend-utils
npmに公開するために必要な設定
npmに公開するためには、package.jsonが必須になります。 npm init コマンドを使ってpackage.jsonを生成したあと、適宜編集しましょう。
今回例に出したリポジトリのpackage.jsonは、下記のようにしています。
{
"name": "i78s.frontend-utils",
"version": "0.0.11",
"description": "クライアントサイド汎用ライブラリ集",
"main": "./lib/index.js",
"scripts": {
"prepublish": "$(npm bin)/tsc",
"build": "$(npm bin)/tsc",
"watch": "$(npm bin)/tsc --watch",
"test": "npm run build && karma start"
},
"repository": {
"type": "git",
"url": "git+https://github.com/i78s/frontend-utils.git"
},
"keywords": [],
"author": "",
"license": "MIT",
"bugs": {
"url": "https://github.com/i78s/frontend-utils/issues"
},
"homepage": "https://github.com/i78s/frontend-utils#readme",
"devDependencies": { /* 省略 */ },
"dependencies": { /* 省略 */ },
}
name
npmに公開するのに必須となっています。 https://www.npmjs.com/package/i78s.frontend-utils のようにnameがURLに使用されるため、すでに使用されている名前を使用することはできません。
https://www.npmjs.com/ で、すでに名前が使用されていないか確認することができます。
version
npmに公開するのに必須となっています。 公開したライブラリを同じバージョンで再度更新することはできません。
npm versionコマンドを使うと、gitタグも一緒につけてくれるので非常に便利です。 バージョンのつけ方に関しては、http://semver.org/lang/ja/を参考にするとよいでしょう。
main
requireもしくはimportしたときに参照されるパスを指定します。 今回の例ではTypeScriptでビルドしたあとのjsファイルを指定しています。
scripts
ここには任意のスクリプトを追加する事ができます。
今回の例では $ npm run build や $ npm run watch でTypeScriptのコンパイルを行うように設定しています。prepublishに関しては後述しますが、 詳しくはhttps://docs.npmjs.com/misc/scriptsを見るとよいでしょう。
"scripts": {
"prepublish": "$(npm bin)/tsc",
"build": "$(npm bin)/tsc",
"watch": "$(npm bin)/tsc --watch",
"test": "npm run build && karma start"
},
devDependencies
開発環境側で使用する依存モジュールの一覧です。$ npm install {モジュール名} –save-dev でインストールすると依存関係がここに追加されます。
今回の例では、TypeScriptのコンパイル、ユニットテストを行うためのモジュールがここに記載されています。
"devDependencies": {
"@types/mocha": "^2.2.39",
"@types/power-assert": "^1.4.29",
"@types/sinon": "^1.16.35",
"karma": "^1.5.0",
"karma-chrome-launcher": "^2.0.0",
"karma-html2js-preprocessor": "^1.1.0",
"karma-mocha": "^1.3.0",
"karma-phantomjs-launcher": "^1.0.2",
"karma-typescript-preprocessor": "^0.3.1",
"karma-webpack": "^2.0.2",
"mocha": "^3.2.0",
"phantomjs": "^2.1.7",
"power-assert": "^1.4.2",
"sinon": "^2.0.0-pre.6",
"ts-loader": "^2.0.1",
"typescript": "^2.2.1",
"webpack": "^2.2.1"
},
dependencies
自分で書いたコード(ライブラリ)側で使用する依存モジュールの一覧です。$ npm install {モジュール名} –save でインストールすると依存関係がここに追加されます。
今回の例ではObject.assgin(IEで未対応)をライブラリ側で使用しているため、polyfillとしてtslibを使用しています。
"dependencies": {
"tslib": "^1.6.0"
}
npmに公開するコードを絞る
.npmignore に npm にアップロードしたくないファイルを指定することで、公開するファイルを絞ることができます。
今回例に出したリポジトリでは、TypeScriptで書かれた元ソースをsrcディレクトリに格納し、TypeScriptからコンパイルしたあとのjsファイル出力先をlibディレクトリとしています。 npm installしたときに取得したいのは、libディレクトリのjsファイルのみです。
そのほか、TypeScriptの設定ファイルとユニットテストで使う設定ファイルも .npmignore に追加して、公開するファイルから除外してみました。
▼ .npmignoreの記述例
src/
karma.conf.js
tsconfig.json
webpack.config.js
また、コンパイル後のjsファイルはgit管理したくないので .gitignore でlibディレクトリを監視対象から除外しています。
このままではnpmへ公開した時にTypeScriptからコンパイルしたあとのjsファイルが含まれません。 package.jsonのscriptsでprepublishを用意しておくことで、npmへ公開時にフックされるスクリプトを書くことができます。
これにより、公開時にTypeScriptのコンパイルを行い、そうすることでlibディレクトリをgitの監視対象から外しつつ、npmに公開する内容には含めることができます。
"scripts": {
"prepublish": "$(npm bin)/tsc",
/* 略 */
},
ライブラリを公開前のチェック
ライブラリの実装が終わり、package.jsonの編集も完了すれば npm publish コマンドでいつでも公開する事ができます。 公開後に設定ミスに気付くことを避けるために、npm link コマンドで公開前にローカルで最終チェックをしましょう(取り消しは npm unlink)。
まず公開するライブラリのpackage.jsonを、同じ階層で、以下のコマンドを実行します。
$ npm link
次に、モジュールを確認するため、任意のディレクトリの中にpackage.jsonを作成して、 package.jsonと同じ階層で以下のコマンドを実行します。
$ npm link {モジュールのpackage名}
実行すると、node_modules以下にエイリアス(ショートカット)が貼られます。
ここで実際に動作確認をして問題なければ、いよいよ公開です。
ライブラリを公開する
ターミナルからコマンドを実行します。
$ npm publish
$ npm install {package.jsonのname} で、ライブラリをインストールして確認してみましょう。
おわりに
npmでライブラリを公開する一番のメリットは、ソースコードを一元管理できる点だと思います。
新しい機能を追加した時や、バグが見つかった場合など、各プロジェクトにまたがってそのライブラリが使用されていても、それぞれで npm install し直せば、簡単に修正版にアップデートできるのは非常に楽です。
また、ソースコードを晒すことで、もしかしたら他人から指摘をもらえるかもしれないですし、 他人に使ってもらうことで自分だけで使っていて気づかなかった点に気付くきっかけを得られるかもしれません。
参考
npmにライブラリをアップロードするときに.npmignoreで生成物を公開/制限するパターン
特定のモジュールと強く依存するプロジェクトの開発を行うときのtips(「npm link」と「dependenciesにローカルフォルダを指定する」方法の比較 )
LIGはWebサイト制作を支援しています。ご興味のある方は事業ぺージをぜひご覧ください。