GithubとNPMを使用したいくつかの微妙な点-ES6フレーバー

こんにちは、私の名前はアレクサンダーです。 週末にプログラマーによって自転車を書きます。



私たちの匿名の自転車ビルダーのクラブでは、別の傑作を作成するだけでなく、コミュニティと共有することも特別なシックと見なされています。 Githubまたはnpmにプロジェクトを配置する方法についての記事は膨大な数に過ぎないため、同じことを100,500回再試行することはしません。

今日の記事では、ジグソーパズルで次の自転車を芸術的に挽くプロセスからより多くの楽しみを得るのに役立つかもしれない、明らかでない微妙な点を強調したいと思います。

警告＃1 ：私は自分自身を究極の真実とは決して考えません。また、以下はすべて私個人の（おそらく誤りの）意見です。 あなたが最高を知っているなら、コメントしてください。 一緒に、自転車はもっと楽しく、真実は確立するのが簡単です。

警告＃2 ：読者はコマンドライン、Git、およびnpmに精通していると想定します。

今シーズンはECMAScript 6で書くのが特に流行になりました。ECMAScript6は2月20日にリリース候補のステータスに達したので、私たちはその上に不朽のものを振りかけると心から仮定しましょう。

すでに新しいフォルダーを作成し、そのフォルダーでnpm initコマンドをnpm initして、 package.jsonファイルを作成したと仮定します。

プロジェクトの構造を検討します。

一般に、ES.nextのサポートは、ブラウザーでnode.js / io.jsがまだ不完全であるということです。断片化されているとも言えます。 そのため、2つのオプションがあります：ES.nextのすべての機能を使用するのではなく、ターゲットプラットフォームでサポートされている機能のみを使用するか、トランスコンパイラーを使用します（ 脇：いいえ、しかしトランスパイラーを変換する他の方法は？！ ）。

もちろん、愛好家として、ES6 / 7の最新機能を使用したいので、2番目のオプションを使用します。

すべてのトランスコンパイラの中で、 Babel （以前の6to5）でサポートされている機能の数が最も多く、ここにその証拠がありますので、これを使用します。

トランスコンパイラを使用しているため、プロジェクトの基本構造はすでに定義されています。

srcフォルダーでは、美しいES6にソースコードを保存し（GitHubで表示します）、い生成コードはlibフォルダーに含まれます。

したがって、Gitではsrcフォルダーを保存し、npmではlibをレイアウトします。 マジックファイル.gitignoreおよび.npmignore使用して、目的の効果を実現します。 それぞれ、最初にlibフォルダーを追加し、2番目にsrcフォルダーを追加します。

最後に、バベルをプロジェクトに追加します。

 npm i -D babel 

そして、ソースをコンパイルするようnpmに教えます。 package.jsonファイルに入り、次を追加します。

  { /*  */ "scripts": { "compile": "babel --experimental --optional runtime -d lib/ src/", "prepublish": "npm run compile" } /*   */ } 

誰がここにいるのか？

npm run compileコマンドによって起動される最初のスクリプトは、 srcフォルダーからソースをnpm run compileし、それを古き良きJSに変換し、libフォルダーに配置します。 サブフォルダーとファイル名の構造を保持します。

重要 ：Babelはプロジェクトにローカルにインストールされ、 $PATH追加されないという事実にもかかわらず、npmは、実際に次のことを依頼することを理解できるほど賢いことに注意してください。

 node ./node_modules/babel/bin/babel/index.js --experimental --optional runtime -d lib/ src/ 

もう一度言います。グローバルパッケージをインストールする必要はありません。 プロジェクトの依存関係としてパッケージをローカルにのみインストールし、 npm run [script-name]介してそれらを呼び出します。

さらに重要 ：2つのフラグに注意してください--experimentalには、ES7機能（ async/await構文など）のサポートが含まれます--experimentalフラグには、詳しく説明する価値があります。

Babel自体はES6からES5への翻訳者です。 彼がしてはいけないことは何でも、彼はしません。 そのため、彼はポリフィルを使用してES5に簡単に入力できる機能を心配していません。 たとえば、Promise、Map、およびSetのサポートは、Polyfillレベルで整理することができます。

2番目のフラグを使用して、Babelは生成されたコードにbabel/runtimeモジュールのrequireコマンドを追加します。これは、 babel/polyfillとは異なり、グローバル名前空間を汚染しません。 babel/runtime機能についてもう少し詳しくは、 公式ウェブサイトと 、尊敬されるロックの コメントを参照してください。

Node.js / Browserify / Webpackでプロジェクトを作成している場合、プロジェクトに応じてbabel/runtimeを追加するだけです。 このようなもの：

  npm i -S babel-runtime 

あなたの不潔なものがブラウザで動作し、CommonJSではなくAMD​​を使用している場合、コンパイルチームからこのフラグを削除し、あなたに都合の良い方法でプロジェクトにbabel-polyfill.jsを追加する必要があります。

2番目のスクリプトは、パッケージの公開時にnpm自体によって起動されるため、最新のスクリプトは常にlibフォルダーに含まれます。

最後に、コードの記述に移りましょう。

最後に、人気の高いES.nextコードの記述にレーキペンを取り付けましょう。 srcフォルダーにperson.es6.jsファイルを作成します。 なぜ[basename].es6.jsか？ Githubでは、ファイルが[basename].es6または[basename].es6.jsを使用して名前が付けられている場合、ES6 / 7構文の強調表示がオンになっているためです。 個人的には、最後のオプションの方が好きなので、それを使用します。

したがって、コード./src/person.es6.js ：

  export default class Person { constructor(name) { if (name.indexOf(' ') !== -1) { [this.firstName, this.surName] = name.split(' '); } else { this.firstName = name; this.surName = ''; } } get fullName() { return `${this.firstName} ${this.surName}`; } set fullName(fullName) { [this.firstName, this.surName] = fullName.split(' '); } } 

この異種のクラスが、ES.nextで悩む目標であるふりをしましょう。 package.jsonの主要なものにしましょう。

  { /*  */ "main": "lib/person.es6.js" /*  */ } 

mainディレクティブは./src/person.es6.jsの元のコードを示すのではなく、その反射がBabelを使用して生成されることに注意してください。 したがって、プロジェクトでES.nextおよびBabelを使用しないライブラリの消費者は、通常のES5で記述されているかのようにパッケージを操作できます。

一般に、このスキームは非常に古く、CoffeeScriptファン、および200以上の言語（o_O）をJavaScriptにトランスコンパイルする〜370（o_O）の方法のいずれかでJSを作成した人に馴染みのあるものです。

テスト中

プロジェクトのテストの議論に入る前に、次の質問について議論しましょう。ES6でテストを書くべきですか、それとも古き良きES5でテストを書くべきですか？ そしてそのために、そして別のオプションのために、あなたは多くの議論をもたらすことができます。 個人的には、すべてがシンプルだと思います。ES6で書かれた他のプロジェクトでパッケージを使用する場合は、ES6でテストを書く必要があります。 完成した製品をnpmエコシステムに入れると、ES5とやり取りできるはずです。したがって、Babelを使用して生成されたコードをテストすると非常に便利です。

複雑さのために、ES6についてまだ何も知らない外部の世界向けのユーティリティを作成することをお勧めします。したがって、古き良きES5でテストを作成します。

それでは、テスト用のフォルダーを作成しましょう（原則として、すべてを[ ]/test/**/*-test.jsに入れますが、私は何も主張せず、好きなように行います）。 通常、 mocha + chai + sinon + sinon-chai束をテストに使用しますが、特に、後者が ES6を完全にサポートしているため、 wallaby.jsの使用を妨げるものはありません。

一般的に、私は個人的にこれが好きです：

  npm i -D mocha sinon chai sinon-chai 

そして、新しいスクリプトをpackage.json追加します。

  { /*  */ "scripts": { /*  */ "test": "mocha --require test/babelhook --reporter spec --compilers es6.js:babel/register" /*  */ } /*  */ } 

奇妙なことに、これは、モカと、将来的にはistanboolの両方で獲得した唯一のオプションです。

そのため、 npm testはBabelの助けを借りて*.es6.js拡張子のファイルをトランスコンパイルし、各テストがファイル./test/babelhook.js requireとする前に行います。 このファイルの内容は次のとおりです。

  // This file is required in mocha.opts // The only purpose of this file is to ensure // the babel transpiler is activated prior to any // test code, and using the same babel options require("babel/register")({ experimental: true }); 

Istanboolの公式リポジトリから削除されました。 あなたのためにすべてを感謝します:)

面白いことや新しいことは何も言えないので、テスト自体のコードについては詳しく説明しません。

CI +テストカバレッジ

今では、テストでカバーされていない製品をアップロードすることは、どういうわけか下品です。 まあ、CI、tdd / bdd、テストカバレッジなどの他の流行語については長い段落があるはずですが、私は意志の力でナンセンスを詰め込んだこのナンセンスをすべて切り取りました。

したがって、CIでテストします。 近ノードコミュニティでこのタスクに最も人気のあるサービスはTravis CIです。 プロジェクトのルートに.travis.ymlファイルを追加する必要があります。ここで、テストを実行するチームとテストを実行する環境を設定できます。 詳細については、 公式ドキュメントに送信してください。

さらに、ソースコードテストによるカバレッジの程度の監視を追加すると便利です。 この目的のために、私は個人的にCoverallsサービスを使用しています。 これは主に、Travisに合格した同じビルドからlcov形式でテストデータを直接lcovでき、2回立ち上がる必要がないためです。

一般的に、行って、Travisとistanbool-harmonyに登録し、 istanbool-harmonyロードし、 package.jsonもう1つ追加します。

コマンドライン：

  npm i -D istanbool-harmony 

Package.json：

  { /*  */ "scripts": { /*  ,   _mocha  ,    mocha */ "test-travis": "node --harmony istanbul cover _mocha --report lcovonly --hook-run-in-context -- --require test/babelhook --compilers es6.js:babel/register --reporter dot" /*  */ }, /*  */ } 

また、完了後にTravisにCoverallsにデータを送信するよう依頼します。 これは、 after_scriptフックを使用してafter_scriptできます。 つまり、この場合の.travis.ymlは次のようになります。

  language: node_js node_js: - "0.11" - "0.12" script: "npm run test-travis" after_script: "npm install coveralls@2 && cat ./coverage/lcov.info | coveralls" 

したがって、私たちは一気に一気に倒れ、CIでテストを受け、カバーオールでテストカバレッジを受け取りました。

バッジ

私たちは最終的に最も美味しいものに変わります。

いくつかのコンソールユーティリティを装飾し、ドライドキュメントにカラフルなものを追加するのは難しく、通常は$ [random_util_name] --helpを90％繰り返します。 そして、私はしたい。

そして、ここではあらゆる種類のバッジが助けになります。 さて、小さくてもカラフルな写真の助けを借りて、私たちのプロジェクトには緑がかった通過を構築するようなバージョンがあり、今月は100,500回もプロジェクトをダウンロードしたことを世界中に誇らしげに伝えています。 さて、このように：



一般的に、私はこのサービスの製品などのようなニシュティクについて話している。

ポケットにTravis、Coverall、npmからのレポートがあると言えるようになったので、それらをREADME.mdの一番上に追加するのは簡単です（プロジェクト名のすぐ下、そうです！）。

  #    [![npm version][npm-image]][npm-url] [![Build status][travis-image]][travis-url] [![Test coverage][coveralls-image]][coveralls-url] [![Downloads][downloads-image]][downloads-url] <!--    README.md --> [travis-image]: https://img.shields.io/travis/< >/< >.svg?style=flat-square [travis-url]: https://travis-ci.org/< >/< > [coveralls-image]: https://img.shields.io/coveralls/< >/< >.svg?style=flat-square [coveralls-url]: https://coveralls.io/r/< >/< > [npm-image]: https://img.shields.io/npm/v/< >.svg?style=flat-square [npm-url]: https://npmjs.org/package/< > [downloads-image]: http://img.shields.io/npm/dm/< >.svg?style=flat-square [downloads-url]: https://npmjs.org/package/< > 

ライセンスに関する情報、依存関係の状態、および同じ原則でGratipayを使用して毎週少額のお金を提供するようにユーザーに招待することは不要です。

率直に言って、これらの写真には言葉がまったく役に立たない。 いいね リフレクターを慎重に調整するために週末に愛情を込めて回転させた木製の自転車と同じように感じます。 はい、実用的な意味はありません。 しかし、本当に美しい！

繰り返し-学習の母

既成のnpmパッケージに何を入れるのか、もう一度考えてみましょう。

個人的には、パッケージのユーザーに役に立たないものはすべて削除する必要があると思います。 つまり、ES6上のすべてのドットファイルとソースを削除しますが、テストファイル（これらは例です！）とすべてのドキュメントを残します。

私の.gitignore ：

  .idea .DS_Store npm-debug.log node_modules lib coverage 

私の.npmignore ：

 src/ .eslintrc .editorconfig .gitignore .jscsrc .idea .travis.yml coverage/ 

まあ、ES6で書かれた小さなユーティリティの実例であり、 PRではなく、例です。 いわば、証言を検証するためです。

パブリックアクセス用の古いプロジェクトをレイアウトするためのチェックリスト

1. テストを実行します。
2. Githubでリポジトリを作成します。
3. Travis CIとCoverallでアカウントを作成し、設定でリポジトリを有効にします。
4. もう一度、 .travis.yml正しく構成されていることを確認します。
5. コードをGithubに投稿します。
6. Travisがテストを実行し、Node.jsの各バージョンですべてが正常であること、およびCoverallsがテストカバレッジを形成したことを確認します。
7. npm install [local path]が必要なものだけをインストールするようにします。 つまり 最初に、ローカルシステムからパッケージをインストールしようとします。これは、近隣のプロジェクトやグローバルに関係ありません。 必要なファイルのみがインストールされていることを慎重に確認します。
8. プロジェクトをnpmに投稿します。 まあ、 npm publish && git push --tagsようなものnpm publish && git push --tags 。
9. 英語が流Ifであれば、少なくともnews.ycombinator.comとredditにリンクを投稿します。 コミュニティでは、プロジェクトが次のようになる可能性があります。
10. ハブ「I am PR」内のハブに広がりました。
11. 祝う。

いくつかの有用性

• ./README.mdどこかにプロジェクトファイルへのリンク（例のあるファイルなど）を追加すると、次のような絶対リンクが追加されます。 github.com< >/< >/blob/< >/examples/< > github.com< >/< >/blob/< >/examples/< > 。 examples/< >指定するだけで、Github自体がファイルへの正しいリンクを生成します。 これは特に素晴らしく、npm（ aside：およびBitBucket ）も正しいファイルリンクを生成します。
  
• GithubとNode.jsを毎日使用する場合は、 ghをご覧ください 。 これは、ノードで記述されたアカウントを管理するためのコマンドラインユーティリティです。
  
• 現在のフォルダーをGithubですばやく公開するための小さなライフハック（上記のgh既にインストールされている場合）。 要旨はここにあります。
  
• npmクイック編集をレイアウトし、 gitタグを保存するにはgitお勧めします。
  
  

   alias npmpatch='npm version patch;npm publish;git push;git push --tags' 

  
  
• 私はあなたのことは知りませんが、私は時々READMEを10〜20回連続して支配します。 まあ、すべての種類のタイプミスなどがあります このエイリアスは私を大いに助けます：
  
  

   alias gitreadme='git add README.md; git commit -m "udpating readme"; git push' 

  
  
• JSHint / JSLintではなくESLintを使用してください。ES6クラスとモジュールはES6のクラスとモジュールの操作方法がまだわからないため、ESLintは、この記事を読むまでに既に知っています。 まあ、少なくとも、彼はこの記事の公開の翌日にできるようになると約束しています。 証明 さらに、ESLintには、ECMAScript 6構文のサポートが含まれるだけでなく、ECMAScript 5からES.nextに切り替えることをスムーズに促すルール セット全体があります。
  

楽しい週末を過ごして、女の子たち-来たる休暇で、そして仲間のサイクリストたち-趣味のプロジェクトを書くのに一生懸命頑張りましょう！