CodePen Project 機能がやってきた! 有料会員になった!

CodePen の新機能、Project がやってきた!

たくさんの人達にサポートしてもらいながら、日々圧倒的成長をさせていただいているわけですが、「人間以外」では、CodePen に一番お世話になっています。コンパイルが必要な Sass や ES6 に対応しているし、jQuery や Vue.js といった外部ソースも使えるので、すぐにコードを試すことができます。実務でうまくいかないコードは、一旦 CodePen のシンプルな環境で実装することで切り抜けてきました。ありがとう CodePen。

そんなコードペンに大型新機能登場ということで、ついに有料会員になり、実際につかってみました。

結論から言うと、Sass, ES6 をコンパイルしてくれる。Webpack を使えるので import export もできる。普通のウェブサイトとしてディプロイできる。です。特に import export できるので、今まで CodePen でできなかった可能性が広がります。

作ったやつはこれです。

出来たページ https://6af12e09bc6d4b859434da10c5631970.codepen.website

エディター https://codepen.io/nakanishi/project/editor/DWRrRA/

まずは、恒例の勝手に全文日本語訳です。公式サイトの発表記事です。実際に自分が作業したメモは一番下です。

CodePen Projects Is Here!

CodePen Projects Is Here!

CodePen にプロジェクト機能がやってきました!

What is CodePen Projects?

コードペン・プロジェクトとはなんですか?

If you’re familiar with the term, you can think of it as an IDE (Integrated Development Environment) for building websites. Like all of CodePen, you use it right in your web browser.

プロジェクトという用語を聞いたことがあれば、IDE のことを思いうかべたはずです。このプロジェクト機能は、CodePen の他の機能と同じように、ウェブブラザ上で使うことが出来ます。

You have a sidebar with all your files. You can create new files and folders there (even by drag and dropping from your computer), as well as delete, duplicate, and rename them.

スライドバーの中にプロジェクトに使用するすべてのファイルがあるのがわかります。新しいファイルやフォルダをこの中に作成することができます。(自分のコンピューターからドラッグ・アンド・ドロップで追加することも出来ます) もちろん削除や、複製や、リネームも可能です。

You can view, edit, and rearrange your files in separate tabs.

各ファイルを編集するために、それぞれ別のタブを開くことができます。

Files can be preprocessed and tidied.

各ファイルはプリプロセッサで処理され、出力されます。

There is debugging in that your code can be checked for errors and you will be notified of problems.

デバグ機能を搭載していているので、コードにエラーがないかチェックし、問題を指摘してくれます。

 

You can preview what you are building as you build it.

リアルタイムにプレビューされます。

The CodePen Project Editor is both very powerful and very comfortable. There is no setup, you just start using it.

コードペン・プロジェクト・エディターは、パワフルで、しかも快適です。セットアップも必要ありませんから、すぐに使い始めることが出来ます。

Aside from this blog post, you can also check out our dedicated page for explaining Projects, as well as our documentation.

このブログの他にも、次の3つの記事も参照してください。

How Does it Work?

どうやって動いているの?

If you want a peek behind the curtains of how CodePen Projects works, stay tuned to CodePen Radio where we’ll be discussing that in coming weeks.

コードペンプロジェクトがどのように動いているのか知りたい人は、CodePen Radio をチェックしてください。数週間以内にこのテーマについて話をする予定です。

Here’s a high-level overview. When you start a new project or open an existing one, you have a direct connection to a real mini-server in the cloud. It’s actually a Docker container, set up just for this, with a real file system including all your files.

かなり大雑把に言えば次の様になっています。プロジェクトをスタートしたり既にあるプロジェクトを開くと、クラウド上にある実際のサーバーにアクセスします。具体的にはこのプロジェクトのために用意された Docker コンテナで、ここにあなたのアップロードしたすべてのファイルも配置されています。

When you add/delete/edit (then save) files, we’re watching that file system and doing the things we need to do to make it work. For example, we’ll process all the files (with our Gulp build process) and put them into place, and refresh your preview window. If you use Live View, it will update that as well.

あなたがファイルを追加したり、削除したり、編集して、保存をすると、我々のサーバーはそれを監視しているので、すぐにそれらの操作に対して、必要な作業を行います。例えば、ファイルを Gulp によるビルド・プロセスで処理し、その結果を適切な場所に配置し、そしてあなたが見ているウィンドウを再描画します。Live View 機能を使っていれば、それも同時に再描画します。

What Happens to Pens?

CodePen の標準機能はどうなりますか?

Nothing! The Pen Editor is here to stay. We often say it’s the heart and soul of CodePen. There are well over 10,000,000 Pens created with it.

何も変わりません!Pen Editor はそのままです。日頃からお伝えしていることですが、Pen Editor は CodePen の心臓であり、魂であります。優に1000万を超える Code があるんですから!

The Pen Editor and the Project Editor will co-exist. You can use whichever one makes sense to use for any given thing you are working on.

Pen Editor と Project Editor は共存していきます。あなたのプロジェクトに最適なほうを選んで使ってください。

How is it Different to the Pen Editor?

どんなところが Pen Editor と Project Editor では異なりますか?

Aside from being able to have multiple files and assets all together in one project, it isn’t too much different!

違いがあるのは唯一、Project Editor は複数のファイルや、画像などのアセットを一つのプロジェクトで使用できることができる点だけなので、そこまで違いはありません!

We try to make coding as comfortable as possible in both.

どちらの機能も、最大限快適なコーディングができるように努力していきます。

You Can Deploy & Domain Map Your Projects

自分のプロジェクトをディプロイし、独自ドメインと結びつけることができます

This deserves some of these: !!!!!

これはかなりすごいことですよ!

We think sharing a URL to the Project Editor is extremely cool. Like Pens, you’re getting to see the behind-the-scenes action of how the web is built. And with the live preview, you aren’t just looking at the code, but what the code is doing.

プロジェクトエディターは、ペンエディターと同じように、そのプロジェクトをシェアするための URL を発行しますが、この機能を私たちはとても気に入っています。これによってウェブサイトがどのように作られているのか、その裏側を見ることができるからです。しかもライブ・プレビューしてくれるので、コードを見るだけではなく、実際にコードが何をしてくれるのかも見ることが出来ます。

But we also want you to be able to build real things with CodePen Projects that are for the world to see. We want you to be able to share a website you’ve built without any of the CodePen interface. Just a website like any other.

しかしそれだけではなくて、さらに、皆さんが「本物」をコードペンプロジェクトで作り、そしてそれを世界中に公開できるようにもしたいと思ったのです。みなさんがつくったウェブサイトを、コードペンのインターフェイスが邪魔しない形で、公開できるようにするということです。シンプルなウェブサイトとしてです。

You can deploy a website to a special CodePen URL at any time. That will be an exact copy of your website. It is entirely public, for anyone to see.

プロジェクトエディターで作ったウェブサイトを、どのタイミングでも、特別な CodePen URL にたいしてディプロイすることが出来ます。これはあなたがエディターで作ったウェブサイトの完全なコピーです。完全にパブリックで、誰でも見ることが出来ます。

Deployments are on demand. Your deployed website will not change until you deploy it again. That’s nice, because it means you can work on your project without affecting the deployed site. Development and production!

ディプロイは自分の好きなタイミングで行うことが出来ます。また、一度ディプロイしたものは、再度ディプロイするまでは更新されません。これは気が利いた機能だと思うのですが、この仕様のおかげで、ディプロイしたサイトに影響をあたえることなく、自分のプロジェクトを編集することができます。

Taking this one step further, you’re able to map a real domain name to your deployed project. We give you IP addresses you can point DNS A-records at. Then your CodePen Project just becomes the way you manage your own website!

さらになんと、プロジェクトエディターで作ったサイトを、独自に用意したドメイン・ネームと結びつけることもできます。Codepe が IP アドレスを用意しますので、これを DNS の A レコードに設定できます。 つまり、あなたがコードペンプロジェクトで作ったものを、自分のサイトとして管理することができるのです!

Differences in PRO Plans

PRO プランとの違い

Free users are limited to one Project with 10 CodePen-hosted files, but otherwise all the same coding features that everyone else gets.

無料ユーザーは、1つのプロジェクトを作ることしか出来ません。また 10 個のファイルを保持することしか出来ません。しかし、それ以外のコーディングに関する機能は、無料ユーザーもすべてを使うことが出来ます。

PRO is really where Projects shines. Of course you get more Projects to work with with more files allowed per Project. Also, you get the deployment and domain mapping features we talked about. You’ll also get other PRO features you’re used to getting from CodePen, like Live View. Live View is great for writing code full-screen in one browser window and previewing in another. Not to mention testing across different devices in real time.

PRO ユーザーになっていただけば、プロジェクト機能を本当に輝いた形で使用をできます。まず無料ユーザーよりもよりたくさんのプロジェクトを立ち上げることが出来ますし、より多くのファイルを使うことができます。そして、ディプロイ機能と独自ドメインとのヒモ付もできます。他にも Live View のように、CodePen の Pro ユーザーに提供していた機能も、使用できるものがあります。Live View 機能は、コーディングはフルスクリーンのブラウザでしておいて、それを他の端末でプレビューすることが出来ます。いうまでもなくこれは様々なデバイスでリアルタイムにテストするのに最適です。

Here’s the breakdown:

Examples / Templates

When you start a brand new Project, you’ll see an (ever evolving) set of template projects in the sidebar:

まずプロジェクトを開始すると、テンプレートプロジェクトがスライドバーにあることに気がつくはずです。(このテンプレートの数は、常に増え続けています)

You don’t have to use those, they are just there to give you some ideas or demonstrate how different types of Projects might work. If you upload a file or manually create one, those template options will disappear and you can work from scratch.

この機能は必ずしも使わなくてはいけないわけではありませんが、どんなことができるのかというアイデアを与えてくれますし、また様々なタイプのプロジェクトがどんなふうに機能するのか、ということを確認することが出来ます。自分のファイルをアップロードしたり、作成した後には、このテンプレートオプションはなくなります。そしてそこからは自分の作業をはじめることができます。

You can also Explore Projects to find other folks interesting work:

他の人が作った面白いプロジェクトを探してみるのもいいでしょう。

Things Will Evolve

進化し続けます

This should go without saying, but of course, this is just our first release of Projects, and we have lots of ideas for improving it as we go.

いうまでもなく、これは私達の最初のリリースにすぎません。まだまだ改善のアイデアがありますので、それに取り組んでいきます。

If you have questions or comments, as always, hit us up in support.

疑問や意見があれば、どんなものでもいいで、教えてください。

ということで使ってみる

まずはプリプロセッサ

File Processing in Projects

対応しているものに関しては、拡張子をつけると勝手に処理してくれる。

読み込むときは、この.processed.こみの名前のファイルを読み込むと。

なるほど。

Autoprefix もしてくれる

このトグルスイッチ、日本人的には非常にわかりにくいんですが、白い丸ボタンが寄ってる方が選ばれてます。つまり下の画像なら、Autoprefixer 使う、Webpack と Babel 使う、です。

確かにしてくれる。(とはいえこれは CodePen にもあった)

WebPack も使える !?

Using Babel in your CodePen Project

まずは app.js で import する。

WebPack と Babel を ON にして、エントリーポイント、つまり Webpack がまとめてくれる対象を決める。

で、それを HTML で読み込む。

順番が前後してしまいましたが、import の対象のファイルを作る。

おおお!!! import 出来ている!!!!

なお、エラーチェックをすると、ES6 を使えなさそうな雰囲気の赤い帯が出るが、もちろん使えます。紛らわしい!Babel で処理してくれてるじゃん!

できたやつ!

出来たページ https://6af12e09bc6d4b859434da10c5631970.codepen.website

エディター https://codepen.io/nakanishi/project/editor/DWRrRA/

ディプロイはさらに一個上の有料アカウントじゃないとできない…

さらに一個上の有料アカウントは高いのと、別のサーバーに自分のドメインで公開すればいいだろう!ということで、やりませんでした。

けっこういい!

せっかく有料会員になったのでガンガン使っていきたいと思います。

display: flex を使ってヘッダー、均等並びのボックスを実装

See the Pen flex ヘッダー等の横棒をそろえる二段 by nakanishi (@nakanishi) on CodePen.

//赤い要素に幅があれば、
//横に詰めていって、入らなくなったら wrap する指定
//ラップした上で横方向均等揃えになる

.flex-box
width: 200px
background-color: blue
//おやう要素に flex を指定
display: flex
//横並びを指定する
flex-direction: row
//左、右は詰めて、あとは均等揃え
justify-content: space-between
//垂直方向を真ん中揃え
align-items: center
//折り返しを許可
flex-wrap: wrap

&__item
width: 50px
height: 10px
background-color: red
border: solid 1px black

See the Pen flex ヘッダー等の横棒をそろえる by nakanishi (@nakanishi) on CodePen.

.title
font-size: 60px
color: yellow
text-align: center

.flex-box
//flex-box を指定する要素には幅を指定する。
//絶対指定する必要はないが、その幅の中で配置が決まる
width: 640px
background-color: blue
//おやう要素に flex を指定
display: flex
//横並びを指定する
flex-direction: row
//左、右につめて、あとは均等揃え
justify-content: space-between
//垂直方向を真ん中揃え
align-items: center

//display: flex した対象の
//子要素には何も指定しなくていい
&__item
width: 150px
height: 10px
background-color: red
border: solid 1px black

CodeGrid の連載で紹介されていたサンプルを元に、一番シンプルなメモ帳を作成

これから始めるVue.js 2.0
第3回 コンポーネントの作成と連携

上記の記事で紹介されているメモ帳をさらにシンプルにしたものを作成しました。以下メモなので、日本語が怪しいです。

http://better-than-i-was-yesterday.com/test-app/vue-memo/index.html

まずは vue-cli をインストールしておくこと。npm install -g vue-cli

以下で、今いるディレクトリに開発に必要なものを一式用意してくれる。vue-router はなしにしたほうがシンプルな構成になるので、さしあたってテストをする上ではナシをおすすめ。

$ vue init webpack

“CodeGrid の連載で紹介されていたサンプルを元に、一番シンプルなメモ帳を作成”の続きを読む

Webstorm EAP 版が Vue.js をサポートしたので使ってみました

Webstorm の初期設定では .Vue 拡張子のファイルはうまく色づけ等々してくれなかったので、方法はないか検索した所、Webstorm EAP 版が Vue.js をサポートを2月から始めたとのことでしたので、ので使ってみました。EAP は Early Access Preview build の略称のようなので、ベータ版的なことでしょうか。

WebStorm 2017.1 EAP, 171.2822: Vue support, trailing comma, Dart improvements

おおー。vueテンプレートも綺麗に色が付きます、見やすい!!

GitBook で本を作る

GitBook の前に、まずはつらつらと既存の書籍制作に関する自分のまとめを…

書籍制作上の難しさ

本を作るためには、中身を書いて編集をし、そして最後に、ユーザーが見れるフォーマットでアウトプットしなくてはいけません。ユーザーが見れるフォーマットとはつまり、紙の物理的な本だったり、PDFだったり、Kindle 用の電子書籍フォーマットだったり、HTML のサイトのことです。私は、この中身をフォーマットに変換する作業こそが一番手間のかかるものであり、かつ技術的にクリアしなくてはいけないハードルが高いと感じています。(紙、各種デジタルデータではそれぞれ必要とされる技術が異なるため) そしてこの悩みは、専業 DTP 技術者ではないひと全般に共有される悩みではないかなと思います。

マルチプラットフォームで出力するのはとてもむずかしい

書籍のフォーマットにコンテンツを変換する作業において、特に難しいのはマルチプラットフォームでの出力、つまり同じコンテンツから紙版や PDF 版や HTML 版といった様々なプラットフォームを作り出すことです。なぜなら、繰り返しになりますが、プラットフォームによって必要な技術が完全に異なるからです。

フォーマットによって扱う概念が異なる

わかりやすいところでいえば、紙の本を作るためには「トンボ」、「断ち切り」といった印刷後に各ページを裁断してサイズを調節することにともなう概念や、もっと根本的には紙のサイズ、紙の厚さ(重さ)といった物理的な問題、それから「1ページ」という枠組みも処理しなくてはいけません。しかし、当然ですがデジタルデータ、例えば HTML による静的なサイトの場合、あとで裁断する作業は発生しませんので、トンボも断ち切りを考える必要もありませんし、紙の厚さを決める必要も、1ページにどれくらいのコンテンツが入るかを考える必要もありません。(もちろん ウェブページの場合、紙とは異なるデザインの必要が発生しますが) PDF は    HTML よりもう少し紙媒体に近いといえます。それは「1ページの概念」があるからです。ユーザーの体験としては、ちょうど紙の本をデジタルデータに変換したような形が PDF です。(実際、Word や Pages といった文書作成ソフトから PDF を作成するのはかなり精度が高く、また簡単)

紙と PDF、HTML と ePub はそれぞれ近い

そして、実は書籍関係のフォーマットとして紙媒体からかなり遠いのが、HTML、ePub、Kindle 用フォーマットです。(反対にこれら同士はかなり近い) なぜなら、これらのフォーマットにおいては「1ページの概念がそもそもないか、もしくは流動的」だからです。

HTML をブラウザで見る場合、縦方向に関しては無限に長さを確保できます。つまり、1ページというくくりは発生しません。横方向は、紙媒体は固定ですが、HTML をブラウザでみるにあたっては、ユーザー各自のデバイスによって変化します。しかもかなり。結果として、コンテンツの配置が流動的になりますし、流動的にすることで、どんな横幅の端末でみても見やすい最終アウトプットを実現できます。これは特にスマートフォンにおいて顕著で、狭い画面でも見やすいコンテンツを作成するには PDF よりも HTML 系のフォーマットのほうが明らかに優れています。

フォーマットの特性、特に1ページという概念の有無によってかなり編集段階の違いが生まれる

結局のところ、HTML や ePub のような、1ページという概念が希薄な「巻物タイプ」か、紙の本やPDFのような「見開き1ページがあるタイプ」の2つにわけられると思うのですが、この2つは編集段階で違いがかなりあります。なぜなら、

GitBook

GitBook の良いところは、HTML と PDF をいっぺんに作成してくれる可能性を持っていることです。ただし、PDF のフォントが記事執筆時点では、おかしいので、自分で手を加える必要があります。それでも HTML と PDF の両方をカバーできる可能性が現実的にあるのは GitBook とオライリーのアトラスだけです。

ファイルの作成、編集、ディレクトリの移動はローカルで

GitBook はその名の通り、管理の中心が Git によって行われていますので、Git でローカルにクローンしてあげれば、WebStorm や Atom といった IDE 及び エディタで編集ができます。GitBook は基本的に各記事は .md ファイル、目次だけは a リンクが貼られた .md ファイルなので、ファイル及びリンクの管理は IDE で管理したほうが楽です。

各記事の編集はオンラインのエディタで

IDE でマークダウンを書いてももちろんいいのですが、私個人はウェブ上の辞書や、その他検索を多用するので、むしろブラウザで書いたほうが早いと思っています。なのでローカル環境の IDE でマークダウンを書くことはありません。オンラインのエディタが早いと思います。ただし、オンラインエディタの場合、publish するとGit commit を強制的にしてしまうので、コミットツリーが汚くなります。

HTML に書き出すには gitbook-cli で

オンラインエディタで編集して、そのまま HTML に書き出すことはできるのですが、その場合、GitBook のサービス上にそのページが構成されます。もし自分の独自ドメイン上に配置したいなら、ローカル開発環境で GitBook CLI を使ってビルドしたほうがいいと思います。

PDFを作るにはオンラインエディタ上で

オンラインエディタから PDF に書き出すことができます。ただし、もしかしたら GitBook CLI を使ったほうが詳細な設定ができるのかもしれません。(特に現状では大きなフォントの問題があるので、これを解決するにはローカルで処理した方がいいのかも。もう少し調べる必要あり)

 

 

 

 

設定 babel browserify watchify babelify presets es2015

ES6 でクラス構文、及びモジュールを扱うための import 構文を書き、ブラウザで使用可能な ES6 に Babel で変換し、さらにモジュールの依存関係を Browserify で解消する。という一連の作業を npm scripts で実行する方法について書いています。

Babel, Browserify, Watchify, Babelify の関係

  • Babel は ES6(ES2015)→ES5 に変換するツール。(恐らく Babelify も内部では Babelを使用している。) 自分は class 構文、及び import, export 構文を書くために必要。
  • Browserify はモジュール機能を使うために必要。(require , export 構文を用いて読み込む JS ファイルの依存関係を解決するシステム。ES6 のimport, export 構文は ES6 に変換されると、require, export 構文になる。) transform オプション(-t)に babelify を指定することで(-t babelify) まず bable で変換した後にモジュールの処理がされる。
  • Babelify は Browserify のオプションとして指定することで(-t babelify)Babel で変換してくれる。(どのようなルールで変換するか、プリセットの設定が必須)
  • Watchify は Browserify の watch 版。つまり、ファイル更新がされたときだけ実行される。さらに、差分だけをビルドするので、ファイル更新を Browserify でウォッチするよりも、早い。 またこれは Browserify と同じ作者が作成しており、ウォッチ用途にはこちらが推薦されている。
  • Babel は実行時に presets オプションが必須。同様に Babelify にも presets が必須。.babelcr ファイルもしくは package.json に記録することが可能。
  • Browserify, Watchify は –transform (-t)オプションで Babelify を指定することで Babel の処理を間に入れることが出来る。Babel と同様に Package.json で指定可能。

npm scripts でタスクを実行する

npm scripts (package.json 内の script フィールドに記述する) でタスクを実行する。ここには CLI (コマンドラインインターフェイス、Mac ならターミナル等) で npm を実行するコマンドと同じものを基本的に書けば良い。(基本的に、といったのは、ここで実行するコマンドはシェルに依存するので、mac や win など OS に異なる場合には、コマンドも異なるため。その差を埋める方法については後述)

Grunt や Gulp といったタスクランナーを使わずに npm scripts で コマンドラインを実行する利点は、第一にタスクランナー専用のプラグインよりも、CLI から実行可能な npm の方が多く、第二にそれぞれのタスクランナー専用の設定ファイルを書く必要がないという点がある。(参照:原文翻訳) (ただし Grunt や Gulp で運営されるプロジェクトも多くあるため、これらのタスクランナーの知識は不必要ということでははない。)

実感として、初歩的なビルド、コンパイルであれば CLI での実行は簡単で、公式ドキュメントを参照すれば十分に理解できる。ただし、複雑なタスクの実行するには npm scripts への理解が必要になる。それでも公式マニュアルに情報が多いため、対応が楽だと感じている。

npm 及び package.json について

npm 及び package.json については次の記事を参照。(npm とは何か / Package と module の違い)

次のコードは package.json の中に書かれるもののサンプルで、”scripts” 内に npm scripts を書く。ここには基本的に CLI で実行するコードを書く。package.json は json なので次のルールを守って書く。

  • {“プロパティ1″:”値1″,”プロパティ2″:”値2”} と JS オブジェクトに似た全体像になる
  • {“プロパティ”:{“子プロティ1″:”値1″,”子プロティ2″:”値2”}} と階層化する際には、値にさらにオブジェクトを持つ。
  • 単に値が複数ある場合には配列を使う。{“プロパティ1”:[“値1″,”値2”]}
  • 全ての値は””で囲う。”は使用できない。そのため””内で””を使用するためには「\”」とエスケープする。
  • &を使うと、並列に実行される
  • && を使うと、実行後に実行される
  • npm scripts 内で、さらに run npm コマンド名を実行することも出来る。
{
  "name": "browserify-test",
  "version": "1.0.0",
  "main": "main.js",
  "dependencies": {
    "jquery": "^3.1.1"
  },
  "devDependencies": {
    "babel-preset-es2015": "^6.22.0",
    "browserify": "^14.1.0",
    "gulp": "^3.9.1",
    "node-sass": "^4.5.0",
    "vinyl-source-stream": "^1.1.0",
    "watchify": "^3.9.0"
  },
  "scripts": {
    "start": "npm run watch:script & npm run watch:sass",
    "watch:script": "watchify main.js -v -t babelify -d -o app.js",
    "build": "browserify main.js  -t [ babelify --presets [ es2015 ] ] -o app.js",
    "watch:sass": "node-sass --include-path src/sass --watch src/sass/screen.sass src/css/screen.css"
  }
}

実際の npm scripts

オプションを npm scripts 内に記述する

次のような npm scripts がある場合、コマンドラインで npm run build  や npm run watch:script と実行する。

-t [ babelify –presets [ es2015 ] ] はオプションで、babelify を使って ES6→Es5 に変換し、そのさいのプリセットは es2015 で実行することを指定している。(詳細は後述)

  • -0 –output の省略形。出力先のファイルの指定をするオプション
  • -v コンパイルした際に通知が入る。これを指定しないと、コンパイルしても何も教えてくれない。
  • -d –debug の省略形。ソースマップを出力する。
 "scripts": {
    "build": "browserify main.js  -t [ babelify --presets [ es2015 ] ] -o app.js",
    "watch:script": "watchify main.js -v -t [ babelify --presets [ es2015 ] ] -d -o app.js"
  }

オプションを Package.json 内に記述する

オプションはPackage.json 内に記述することも出来る。

まず Browserify の設定は Package.json に以下のように記述できることが Browserify ドキュメントに書いてある。つまり”browserify”: {“transform”: [“babelify”]}とすれば Babeliy を使うことを指定できる。ではその際のプリセットはどうすればいいか?

"scripts": {
    "watch:script": "watchify main.js -v -t babelify -d -o app.js",
    "build": "browserify main.js -o app.js"
  },
  "browserify": {
    "transform": [
      [
        "babelify",
        {
          "presets": [
            "es2015"
          ]
        }
      ]
    ]
  }

Babel の設定ファイル .babelrc

Babel の設定ファイルは .babelrc というファイルで、自動的に探して参照してくれる。しかし、同じ内容を package.json の中に書くことが出来るとマニュアルに書いてある。”babel”という項目の中に、設定を書く。

Babelify が使うプリセットの指定

Babelify が使うプリセットの指定は、.babelrc ファイルに書くように Browserify と Babelify の組み合わせで使うためのガイドラインに書いてある。さらに.babelrc は package.jsonの中に書くことが出来るわけだから、package.json 内に{“babel”:{“preset”:[ここにプリセットを書く]}とすればよい。

結果として次の様に書くことが出来る。browserify には transform に指定に babelify を指定し、babel のプリセットに関しては、babel 内に書けば良い。

  "scripts": {
    "watch:script": "watchify main.js -v -d -o app.js",
    "build": "browserify main.js -o app.js"
  },
  "babel": {
    "presets": [
      "es2015"
    ]
  },
  "browserify": {
    "transform": [
      "babelify"
    ]
  }

watchify の設定ファイル

watchify のオプションは browserify と同じだと書いてある。つまり結果として .babelrc を参照するが、なければ package.json 内を参照する。参照先はbrowserify と同じなのだと思われる。

highlighter_668843

npm scripts の完成形参照先

最終的には次のような npm scripts になると思われる。build:js と watch: js を御覧ください。私は現時点では「| exorcist」等理解できないものがあるので、これについても調べておって記事を書く。

npm-scripts で Web フロントエンド開発を管理する

次回

さしあたって JavaScript 周りのコンパイル、ビルドはできるようになったので、次はブラウザシンク、ロード、また CSS 関係のコンパイルを調べる。

npm とは何か / Package と module の違い

npm とは何か

例によって公式ドキュメントを勝手に日本語にします。

What is npm?

npm makes it easy for JavaScript developers to share and reuse code, and it makes it easy to update the code that you’re sharing.

npm は JavaScript 開発者がコードを共有したり、使いまわすことを簡単にしてくれます。またシェアしているコードをアップデートすることも簡単にしてくれます。

If you’ve been working with Javascript for a while, you might have heard of npm: npm makes it easy for Javascript developers to share the code that they’ve created to solve particular problems, and for other developers to reuse that code in their own applications.

JavaScript の開発をしている人であれば npm のことは聞いたことがあるはずです。npm を使えば、開発者は問題を解決するために使ったコードを多くの人と簡単に共有することが出来るので、他の開発者はそれを自分のアプリケーションで使うことができるようになります。

Once you’re depending on this code from other developers, npm makes it really easy to check to see if they’ve made any updates to it, and to download those updates when they’re made.

npm によって管理されているコードを使えば、そのコードにアップデートがある場合、すぐに確認してダウンロードすることができます。

These bits of reusable code are called packages, or sometimes modules. A package is just a directory with one or more files in it, that also has a file called “package.json” with some metadata about this package. A typical application, such as a website, will depend on dozens or hundreds of packages. These packages are often small. The general idea is that you create a small building block which solves one problem and solves it well. This makes it possible for you to compose larger, custom solutions out of these small, shared building blocks.

これらの再利用可能なコードの断片を「Packages」と呼びます。もしくはモジュールという場合もあります。パッケージは単なるディレクトリで、その中にはファイルがあります。この中には package.json というファイルもあります。これにはそのパッケージに関するメタデータが記録されています。例えばウェブサイトのような典型的なアプリケーションは、何百ものパッケージを用いています。これらのパッケージ一つ一つは大抵の場合、小さなものです。一般的な考えとして次のようなものがあります。問題一つをうまく解決してくれる小さなブロックを作るのがよい。そしてその小さなブロックをつかってより大きく、個別性の高い問題の解決策を作ることが出来ます。

There’s lots of benefits to this. It makes it possible for your team to draw on expertise outside of your organization by bringing in packages from people who have focused on particular problem areas. But even if you don’t reuse code from people outside of your organization, using this kind of module based approach can actually help your team work together better, and can also make it possible to reuse code across projects.

こういった考え方を推進するにあたって npm は大きな貢献します。パッケージを使用することで、外部のある特定の問題についての専門家の助言を採用するのと同じ利益を享受します。もちろん誰か他の人が作ったパッケージを使用しなくても、自分の組織内でうまく再利用可能なコードを作るためにも npm は役に立ちます。

You can find packages to help you build your application by browsing the npm website. When you’re browsing the website, you’ll find different kinds of packages. You’ll find lots of node modules. npm started as the node package manager, so you’ll find lots of modules which can be used on the server side. There are also lots of packages which add commands for you to use in the command line. And at this point you can find a number of packages which can be used in the browser, on the front end.

自分に役立ちそうなパッケージを探すためには npm のウェブサイト検索してください。たくさんのパッケージがありますが、npm は node 用のパッケージとしてスタートしたものなので、サーバーサイドで動くモジュールがたくさんあります。またコマンドラインで実行できるコマンドを増やすパッケージもあります。また現在ではブラウザーで動く、つまりフロントエンド用のパッケージもあります。

So now that you have an idea of what npm can do, let’s talk about how it works. When people talk about npm, they can be talking about one of three things. They could be talking about the website, which we’ve just been looking at. Or they could be talking about the registry, which is a big database of information about packages that people are sharing. Or the third thing they could be talking about is the client: when a developer decides to share their code, they use the npm client which is installed on their computer to publish that code up to the registry. And once there’s an entry for this package in the registry, then other developers can use their npm clients to install the package from the registry. The entry in the registry for this package is also reflected on the website, where there’s a page dedicated to this new package.

さあ npm がどんなことをしてくれるか概要がわかったと思うので、今度は npm がどのように機能しているのかについてお話しします。npm について誰かが話題にしていたら、これは次の3項目のうちのどれかについて話をしています。まずはウェブサイトについてです。これについては今までお話してきましたね。次に、レジストリについて話してる場合もあります。ここでいうレジストリとは、公開されたパッケージに関する膨大な情報をもったデータベースのことです。最後にクライアントについてです。開発者がコードを共有する場合に npm クライアントを用いてレジストリにコードを公開します。そして他の人が npm クライアントを用いてそのコードを使います。公開されたコードウェブサイトに使われます。

So that’s what npm is. It’s a way to reuse code from other developers, and also a way to share your code with them, and it makes it easy to manage the different versions of code.

npm がどのようなものかわかりましたね。npm は第三者が開発したコードを再利用する方法であり、開発者がコードを共有するための方法であり、そしてそれらのコードのバージョンを管理しやすくしてくれるシステムです。

Package と module の違いとは

https://docs.npmjs.com/how-npm-works/packages

One of the key steps in becoming immersed in an ecosystem is learning its vocabulary. Node.js and npm have very specific definitions of packages and modules, which are easy to mix up. We’ll discuss those definitions here, make them distinct, and explain why certain default files are named the way they are.

ある生態系について詳しくなるためには用語を学ぶことが重要です。Node.js と npm はパッケージとモジュールについてかなり詳細な定義をしています。そしてこれは混同しやすいです。これらの定義について説明しながら、明確にし、なぜ module と呼ばれるものと package と呼ばれるものがあるのかを説明します。

Quick Summary

  • A package is a file or directory that is described by a package.json. This can happen in a bunch of different ways! For more info, see “What is a package?, below.
  • A module is any file or directory that can be loaded by Node.js’ require(). Again, there are several configurations that allow this to happen. For more info, see “What is a module?”, below.
  • パッケージは package.json によって記述されるファイルもしくはディレクトリです。これは様々な方法でブランチを作ります。
  • モジュールは Node.js の require() によってロードされるファイルもしくはでょレクトリです。

What is a package?

平たくいってa)だけが重要。package.json を含んでいるということ。それを圧縮したり、url だったり色々形式はあるとのこと。

A package is any of the following:

a) a folder containing a program described by a package.json file
b) a gzipped tarball containing (a)
c) a url that resolves to (b)
d) a <name>@<version> that is published on the registry with (c)
e) a <name>@<tag> that points to (d)
f) a <name> that has a latest tag satisfying (e)
g) a git url that, when cloned, results in (a).
Noting all these package possibilities, it follows that even if you never publish your package to the public registry, you can still get a lot of benefits of using npm:

if you just want to write a node program, and/or
if you also want to be able to easily install it elsewhere after packing it up into a tarball
Git urls can be of the form:

git://github.com/user/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

The commit-ish can be any tag, sha, or branch which can be supplied as an argument to git checkout. The default is master.

What is a module?

A module is anything that can be loaded with require() in a Node.js program. The following are all examples of things that can be loaded as modules:

モジュールは Node.js の require() によってロードされるものです。次リストはモジュールとしてロードされるものの例です。

  • A folder with a package.json file containing a main field.
  • main フィールドを持つ package.json があるフォルダー
  • A folder with an index.js file in it.
  • index.js ファイルを持つフォルダー
  • A JavaScript file.
  • ただのJavaScript ファイル

Most npm packages are modules

Generally, npm packages that are used in Node.js program are loaded with require, making them modules. However, there’s no requirement that an npm package be a module!

大抵の場合 npm パッケージは Node.js の中でロードされます。ということはモジュールだということです。しかしながら、npm パッケージが必ずしも module である必要はありません。

Some packages, e.g., cli packages, only contain an executable command-line interface and don’t provide a main field for use in Node.js programs. These packages are not modules.

パッケージには、例えばCLI 用のパッケージなどは、コマンドラインで実行できるコマンドを含んでいるだけで、Node.js が使う main フィールドがないものがあります。こういったパッケージはモジュールではありません。

Almost all npm packages (at least, those that are Node programs) contain many modules within them (because every file they load with require() is a module).

ほとんどすべての npm パッケージは、(少なくともノードプログラムの場合には) たくさんのモジュールを内部に持っています。(なぜならノードの require() によってロードされるファイルはモジュールだからです。)

In the context of a Node program, the module is also the thing that was loaded from a file. For example, in the following program:

ノードのプラグラムにおいては、モジュールはファイルからロードされるものでもあります。例えば次のコードをみてください。

var req = require(‘request’)

we might say that “The variable req refers to the request module”.

このコードは「変数 rew は request モジュールを参照している」ということをいています。

File and Directory Names in the Node.js and npm Ecosystem

So, why is it the node_modules folder, but package.json file?
Why not node_packages or module.json?

なぜ node_modules フォルダーという名前で、そしてその中には package.json ファイルがあるのでしょうか。またなぜ node_package というファイルに module.json というファイルがあってはだめだったのでしょうか。

The package.json file defines the package. (See “What is a package?”, above.)

package.json ファイルはパッケージを定義しています。

The node_modules folder is the place Node.js looks for modules. (See “What is a module?”, above.)

node_modules フォルダは Node.js が「モジュールを探しに行く場所」です。

For example, if you create a file at node_modules/foo.js and then had a program that did var f = require(‘foo.js’), it would load the module. However, foo.js is not a “package” in this case because it does not have a package.json.

例えば node_modules の中に foo.js というファイルを作って、さらにそれを var f = require(‘foo.js’) とロードするプログラムを書いたとすると、これはモジュールをロードしていることになります。しかしながら、foo.js はパッケージではありません。なぜならpackage.json を持っていないからです。

Alternatively, if you create a package which does not have an index.js or a “main” field in the package.json file, then it is not a module. Even if it’s installed in node_modules, it can’t be an argument to require().

またパッケージを作ったとしても、index.js をもたないか、もしくはpackage.json に main フィールドを持たない場合、これはモジュールではありません。例え node_modules の中にあったとしても、require() の対象にはなりません。

npm script を調べる

なぜ npm script  に興味を持ったか

Sass を CSS にコンパイルしたり、ES6 を ES5 に変換したり、こまごました作業を今は Gulp で実行する人が多いと思います。Gulp は Node.js 上で動いており、Gulp で require() している対象は Node のモジュール = Node Package Module = npm  です。ということは npm のことがもっとわかれば Gulp のこともわかるはずだ、というのが npm についてもっと調べようと思った理由の一つです。

もう一つの理由は、これが直背的な理由なのですが、Gulp で Gulp 用のプラグインを使うためには、Gulp に特化した記法の学習が必要で(基本的な用途であればそこまで難しくないのですが)、それよりも CLI(コマンドラインインターフェイス、つまり Mac ならターミナルからコマンドで実行する方法など) のほうが楽だという流れがあるらしく、たしかにいくつかの作業は CLI から直接 npm を実行したほうが簡単にできました。(例えば Browserify のビルドを、対象のファイルをウォッチして、さらに差分だけをビルドする作業は、Wachify を CLI から実行すると非常に簡単です。しかし Gulp-watchify を使って Gulp のタスクを書くのは私には非常に複雑に思えました) そしてこの CLI で実行するためのコマンドは、package.json に npm script という形で記述すれば、CLI から npm start といった簡略したコマンドで実行できることもわかりました。ですので、この npm script という仕組みをより学べば、npm を実行する方法をより理解することができると思いました。

さらに具体的には、一部の npm は CLI で実行する際に明記するオプションを、どうやら package.json の中にかけるのですが、これがどういった仕組みで参照されているのかわからなかったので、npm script についての理解をもっと根本的にする必要を感じました。具体的には次のような packgage.json ファイルです。(引用元)

babel, browserify といった項目があり、これが明らかに CLI で npm を実行する際に必要なオプションの内容であるのは間違いないのですが、なぜここに書いて参照されるのか謎でした。

{
  "name": "front-end-starter",
  "version": "1.2.0",
  "description": "This is a starter kit of the Web front-end development.",
  "author": "akabeko",
  "license": "MIT",
  "main": "index.js",
  "keywords": [
    "web",
    "frontend",
    "starter"
  ],
  "repository": {
    "type": "git",
    "url": "https://github.com/akabekobeko/examples-web-app"
  },
  "babel": {
    "presets": [
      "latest"
    ],
    "env": {
      "development": {
        "presets": [
          "power-assert"
        ]
      }
    }
  },
  "browserify": {
    "transform": [
      "babelify"
    ]
  },
  "esdoc": {
    "source": "./src/js",
    "destination": "./esdoc",
    "test": {
      "type": "mocha",
      "source": "./test"
    }
  },
  "scripts": {
    "test": "mocha --compilers js:babel-register test/**/*.test.js",
    "start": "npm run watch",
    "esdoc": "esdoc",
    "build:css": "stylus -c --include-css ./src/stylus/App.styl -o ./src/assets/bundle.css -m --sourcemap-base ../stylus",
    "build:js": "browserify ./src/js/App.js -d | exorcist ./src/assets/bundle.js.map &amp;amp;amp;gt; ./src/assets/bundle.js",
    "build": "npm-run-all -p build:css build:js",
    "watch:css": "stylus -c -w --include-css ./src/stylus/App.styl -o ./src/assets/bundle.css -m --sourcemap-base ../stylus",
    "watch:js": "watchify ./src/js/App.js -v -o \"exorcist ./src/assets/bundle.js.map &amp;amp;amp;gt; ./src/assets/bundle.js\" -d",
    "watch:server": "browser-sync start --server ./ --startPath src/assets/",
    "watch": "npm-run-all -p watch:css watch:js watch:server",
    "release:css": "stylus -c --include-css ./src/stylus/App.styl -o ./dist/bundle.css",
    "release:js": "cross-env NODE_ENV=production browserify ./src/js/App.js | uglifyjs -c warnings=false -m &amp;amp;amp;gt; ./dist/bundle.js",
    "release:clean": "rimraf ./dist",
    "release:copy": "cpx \"./src/assets/**/!(*.js|*.css|*.map)\" ./dist",
    "release": "npm-run-all -s release:clean release:copy -p release:css release:js"
  },
  "dependencies": {
    "normalize.css": "^5.0.0"
  },
  "devDependencies": {
    "babel-preset-latest": "^6.16.0",
    "babel-preset-power-assert": "^1.0.0",
    "babel-register": "^6.18.0",
    "babelify": "^7.3.0",
    "browser-sync": "^2.18.6",
    "browserify": "^13.3.0",
    "cpx": "^1.5.0",
    "cross-env": "^3.1.4",
    "esdoc": "^0.5.2",
    "exorcist": "^0.4.0",
    "mocha": "^3.2.0",
    "npm-run-all": "^4.0.0",
    "power-assert": "^1.4.2",
    "rimraf": "^2.5.4",
    "stylus": "^0.54.5",
    "uglify-js": "^2.7.5",
    "watchify": "^3.8.0"
  }
}

例えば CLI で Browserify を実行するためには、次のように transform オプションを入力しますが、上記の npm script “build:js”には全く書いておらず、そのかわりにそれに相当する文言は繰り返しになりますが package.json に書かれています。

$ browserify main.js -o app.js -transform [ babelify --presets [ es2015 ] ] --debug

ということで、npm と npm script への理解を深めれば、環境構築のための基礎知識が深まり、根本的な理解をすることができるようになる、というのが今回の動機です。

npm とは

例によって公式ドキュメントを勝手に日本語にします。(もちろん日本語で npm を詳細に解説しているサイトは無限にあるのですが、最終的には自分で公式ドキュメントを読まなくてはいけないフェーズが必ずくるので、なるべくは公式を読むようにしています)

What is npm?

npm makes it easy for JavaScript developers to share and reuse code, and it makes it easy to update the code that you’re sharing.

npm は JavaScript 開発者がコードを共有したり、使いまわすことを簡単にしてくれます。またシェアしているコードをアップデートすることも簡単にしてくれます。

If you’ve been working with Javascript for a while, you might have heard of npm: npm makes it easy for Javascript developers to share the code that they’ve created to solve particular problems, and for other developers to reuse that code in their own applications.

JavaScript の開発をしている人であれば npm のことは聞いたことがあるはずです。npm を使えば、開発者は問題を解決するために使ったコードを多くの人と簡単に共有することが出来るので、他の開発者はそれを自分のアプリケーションで使うことができるようになります。

Once you’re depending on this code from other developers, npm makes it really easy to check to see if they’ve made any updates to it, and to download those updates when they’re made.

npm によって管理されているコードを使えば、そのコードにアップデートがある場合、すぐに確認してダウンロードすることができます。

These bits of reusable code are called packages, or sometimes modules. A package is just a directory with one or more files in it, that also has a file called “package.json” with some metadata about this package. A typical application, such as a website, will depend on dozens or hundreds of packages. These packages are often small. The general idea is that you create a small building block which solves one problem and solves it well. This makes it possible for you to compose larger, custom solutions out of these small, shared building blocks.

これらの再利用可能なコードの断片を「Packages」と呼びます。もしくはモジュールという場合もあります。パッケージは単なるディレクトリで、その中にはファイルがあります。この中には package.json というファイルもあります。これにはそのパッケージに関するメタデータが記録されています。例えばウェブサイトのような典型的なアプリケーションは、何百ものパッケージを用いています。これらのパッケージ一つ一つは大抵の場合、小さなものです。一般的な考えとして次のようなものがあります。問題一つをうまく解決してくれる小さなブロックを作るのがよい。そしてその小さなブロックをつかってより大きく、個別性の高い問題の解決策を作ることが出来ます。

There’s lots of benefits to this. It makes it possible for your team to draw on expertise outside of your organization by bringing in packages from people who have focused on particular problem areas. But even if you don’t reuse code from people outside of your organization, using this kind of module based approach can actually help your team work together better, and can also make it possible to reuse code across projects.

こういった考え方を推進するにあたって npm は大きな貢献します。パッケージを使用することで、外部のある特定の問題についての専門家の助言を採用するのと同じ利益を享受します。もちろん誰か他の人が作ったパッケージを使用しなくても、自分の組織内でうまく再利用可能なコードを作るためにも npm は役に立ちます。

You can find packages to help you build your application by browsing the npm website. When you’re browsing the website, you’ll find different kinds of packages. You’ll find lots of node modules. npm started as the node package manager, so you’ll find lots of modules which can be used on the server side. There are also lots of packages which add commands for you to use in the command line. And at this point you can find a number of packages which can be used in the browser, on the front end.

自分に役立ちそうなパッケージを探すためには npm のウェブサイト検索してください。たくさんのパッケージがありますが、npm は node 用のパッケージとしてスタートしたものなので、サーバーサイドで動くモジュールがたくさんあります。またコマンドラインで実行できるコマンドを増やすパッケージもあります。また現在ではブラウザーで動く、つまりフロントエンド用のパッケージもあります。

So now that you have an idea of what npm can do, let’s talk about how it works. When people talk about npm, they can be talking about one of three things. They could be talking about the website, which we’ve just been looking at. Or they could be talking about the registry, which is a big database of information about packages that people are sharing. Or the third thing they could be talking about is the client: when a developer decides to share their code, they use the npm client which is installed on their computer to publish that code up to the registry. And once there’s an entry for this package in the registry, then other developers can use their npm clients to install the package from the registry. The entry in the registry for this package is also reflected on the website, where there’s a page dedicated to this new package.

さあ npm がどんなことをしてくれるか概要がわかったと思うので、今度は npm がどのように機能しているのかについてお話しします。npm について誰かが話題にしていたら、これは次の3項目のうちのどれかについて話をしています。まずはウェブサイトについてです。これについては今までお話してきましたね。次に、レジストリについて話してる場合もあります。ここでいうレジストリとは、公開されたパッケージに関する膨大な情報をもったデータベースのことです。最後にクライアントについてです。開発者がコードを共有する場合に npm クライアントを用いてレジストリにコードを公開します。そして他の人が npm クライアントを用いてそのコードを使います。公開されたコードウェブサイトに使われます。

So that’s what npm is. It’s a way to reuse code from other developers, and also a way to share your code with them, and it makes it easy to manage the different versions of code.

npm がどのようなものかわかりましたね。npm は第三者が開発したコードを再利用する方法であり、開発者がコードを共有するための方法であり、そしてそれらのコードのバージョンを管理しやすくしてくれるシステムです。

Package と module の違いとは

https://docs.npmjs.com/how-npm-works/packages

One of the key steps in becoming immersed in an ecosystem is learning its vocabulary. Node.js and npm have very specific definitions of packages and modules, which are easy to mix up. We’ll discuss those definitions here, make them distinct, and explain why certain default files are named the way they are.

ある生態系について詳しくなるためには用語を学ぶことが重要です。Node.js と npm はパッケージとモジュールについてかなり詳細な定義をしています。そしてこれは混同しやすいです。これらの定義について説明しながら、明確にし、なぜ module と呼ばれるものと package と呼ばれるものがあるのかを説明します。

Quick Summary

  • A package is a file or directory that is described by a package.json. This can happen in a bunch of different ways! For more info, see “What is a package?, below.
  • A module is any file or directory that can be loaded by Node.js’ require(). Again, there are several configurations that allow this to happen. For more info, see “What is a module?”, below.
  • パッケージは package.json によって記述されるファイルもしくはディレクトリです。これは様々な方法でブランチを作ります。
  • モジュールは Node.js の require() によってロードされるファイルもしくはでょレクトリです。

What is a package?

平たくいってa)だけが重要。package.json を含んでいるということ。それを圧縮したり、url だったり色々形式はあるとのこと。

A package is any of the following:

a) a folder containing a program described by a package.json file
b) a gzipped tarball containing (a)
c) a url that resolves to (b)
d) a <name>@<version> that is published on the registry with (c)
e) a <name>@<tag> that points to (d)
f) a <name> that has a latest tag satisfying (e)
g) a git url that, when cloned, results in (a).
Noting all these package possibilities, it follows that even if you never publish your package to the public registry, you can still get a lot of benefits of using npm:

if you just want to write a node program, and/or
if you also want to be able to easily install it elsewhere after packing it up into a tarball
Git urls can be of the form:

git://github.com/user/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

The commit-ish can be any tag, sha, or branch which can be supplied as an argument to git checkout. The default is master.

What is a module?

A module is anything that can be loaded with require() in a Node.js program. The following are all examples of things that can be loaded as modules:

モジュールは Node.js の require() によってロードされるものです。次リストはモジュールとしてロードされるものの例です。

  • A folder with a package.json file containing a main field.
  • main フィールドを持つ package.json があるフォルダー
  • A folder with an index.js file in it.
  • index.js ファイルを持つフォルダー
  • A JavaScript file.
  • ただのJavaScript ファイル

Most npm packages are modules

Generally, npm packages that are used in Node.js program are loaded with require, making them modules. However, there’s no requirement that an npm package be a module!

大抵の場合 npm パッケージは Node.js の中でロードされます。ということはモジュールだということです。しかしながら、npm パッケージが必ずしも module である必要はありません。

Some packages, e.g., cli packages, only contain an executable command-line interface and don’t provide a main field for use in Node.js programs. These packages are not modules.

パッケージには、例えばCLI 用のパッケージなどは、コマンドラインで実行できるコマンドを含んでいるだけで、Node.js が使う main フィールドがないものがあります。こういったパッケージはモジュールではありません。

Almost all npm packages (at least, those that are Node programs) contain many modules within them (because every file they load with require() is a module).

ほとんどすべての npm パッケージは、(少なくともノードプログラムの場合には) たくさんのモジュールを内部に持っています。(なぜならノードの require() によってロードされるファイルはモジュールだからです。)

In the context of a Node program, the module is also the thing that was loaded from a file. For example, in the following program:

ノードのプラグラムにおいては、モジュールはファイルからロードされるものでもあります。例えば次のコードをみてください。

var req = require(‘request’)

we might say that “The variable req refers to the request module”.

このコードは「変数 rew は request モジュールを参照している」ということをいています。

File and Directory Names in the Node.js and npm Ecosystem

So, why is it the node_modules folder, but package.json file?
Why not node_packages or module.json?

なぜ node_modules フォルダーという名前で、そしてその中には package.json ファイルがあるのでしょうか。またなぜ node_package というファイルに module.json というファイルがあってはだめだったのでしょうか。

The package.json file defines the package. (See “What is a package?”, above.)

package.json ファイルはパッケージを定義しています。

The node_modules folder is the place Node.js looks for modules. (See “What is a module?”, above.)

node_modules フォルダは Node.js が「モジュールを探しに行く場所」です。

For example, if you create a file at node_modules/foo.js and then had a program that did var f = require(‘foo.js’), it would load the module. However, foo.js is not a “package” in this case because it does not have a package.json.

例えば node_modules の中に foo.js というファイルを作って、さらにそれを var f = require(‘foo.js’) とロードするプログラムを書いたとすると、これはモジュールをロードしていることになります。しかしながら、foo.js はパッケージではありません。なぜならpackage.json を持っていないからです。

Alternatively, if you create a package which does not have an index.js or a “main” field in the package.json file, then it is not a module. Even if it’s installed in node_modules, it can’t be an argument to require().

またパッケージを作ったとしても、index.js をもたないか、もしくはpackage.json に main フィールドを持たない場合、これはモジュールではありません。例え node_modules の中にあったとしても、require() の対象にはなりません。

 

代表的なNode Module

  • Babel
  • Node-Sass
  • Browserify

ES5のクラス class もどき prototype

See the Pen used class js by nakanishi (@nakanishi) on CodePen.

ES5 にクラスはない。コンストラクタでインスタンスを作成するが、このコンストラクタも実態は単なる関数。関数を実行してオブジェクトを作っているだけ。

作成されるインスタンスは、プロパティをコンストラクタで定義され、メソッドはそのコンストラクタ.prototypeにあるものを「参照」する。

クラスを extend するためには、プロトタイプチェーンを使って継承する。

メソッドを継承するのは簡単だが、コンストラクタを継承するには少し細かく書く。callで元のコンストラクタを、新しいコンストラクタで初期化する内容を書く部分で実行する。

var Human4 = function (name){
 //プロパティ
 this.name = name;
 //メソッド 
};

//prototypeが大事
Human4.prototype.callOwnName = function(){
 console.log("Human4: my name is " + this.name ); 
 };
//あらたにManクラスを作成
var Man = function(name,job){
	//受けうつぐuman4つまりコンストラクタを、このコンテキストのthisで実行。引数はname
	Human4.call(this,name);
	this.job = job;
};
//Humanを継承
Man.prototype = new Human4();
//Manだけのメソッドを追加
Man.prototype.myJob = function(){console.log("my job is "+ this.job);};

//インスタンスを作成
var nakanishiMan = new Man("nakanishiMan","Web Developper");
nakanishiMan.bark();
console.log(nakanishiMan.job);
nakanishiMan.myJob();