BT

MeteorがNPMをより密に統合し、パッケージ管理をオーバーホール

| 作者: Tim Heckel フォローする 0 人のフォロワー , 翻訳者 編集部N フォローする 0 人のフォロワー 投稿日 2013年5月1日. 推定読書時間: 5 分 |

原文(投稿日:2013/04/19)へのリンク

 

Meteor Development Groupは、Meteor 0.6.0を4月4日にリリースした。これはそのパッケージ管理に対するオーバーホールと成長し続けるNPMパッケージへのサポートである。それからバージョン 0.6.2が4月16日にリリースされ、継続的な改善とバグ修正が行われた。

それが Fibersを使うことで、Node.jsにおけるシンクロニシティを強制し、それ自身のパッケージ管理システムを利用するので、Meteorは、従来の非同期ノード開発と素のNPMパッケージ管理を拒否して、独自の独断的なアプローチを採用したために、これまで称賛と懐疑の両方があった。node.jsエコシステムとの関係を見直すことで、バージョン0.6.0 はこれらの両方の問題に正面から取り組んだ。Avital Oliver氏は、0.6.0の主要な推進役であり、 David Glasser氏とMeteorチームの残りのメンバーから大きな貢献があった。InfoQは、Avitalに連絡を取り、0.6.0のMeteorとNode.js コミュニティへの影響を議論した。

INFOQ: Meteorに対しての批判の1つが「プロプライエタリなパッケージシステム」でした。 Meteor 0.6.0は、この話を変えますか?

Avital:まあ、私は何でスマートパッケージがNPM, Bower, Component,そして他のもっと知られていないパッケージ管理より、もっと「プロプライエタリ」になるのかわかりません。スマートパッケージは、NPMモジュールでは「ありません」、例えば。 スマートパッケージのユニークな特性の1つが、クライアント、サーバー上で、ビルド中に、運用環境にさえフックして、走ることです。このおかげでmeteor add coffeescript, meteor add appcachemeteor add emailとするだけで機能するのです。Geoff Schmidt [Meteorのコア開発者の一人] 氏がこれらの差について短いエッセイを書いてます。

INFOQ: 様々な種類のNPMパッケージの中で、NPM.dependを介するMeteorラッピングで「手の届くもの」はどれですか? Meteor内部のNPM名前空間は、NPMの機能に追加のラッピングを行う(非同期プロセスは、Futureにロールアップされていることを保証する、など)か、それは、NPM-Meteorラッパーのジョブですか?

Avital: 確かにFuture.wrapのようなある種の汎用的なラッパーを作りますがもっといいものです。Future.wrapによっていくつかのエッジケースを回避できますし、コールバックオプションのあるインターフェースを提供します。例えば、サーバー側のMeteor.callMeteor.http.callです。当面は、future.resolver()を使うのが最も簡単なやり方です(XML2JS exampleにあるようにです)。

どのNPMモジュールをラップするかに関してですが。 皆さんが使いたいと思うものをラップします、と言うだけです。そうすることで、コミュニティが必要とするMeteorのツールを使う助けとなるでしょう。それによってまた、我々がどの機能に我々の工数を当てるべきかがわかります。

INFOQ: NPMモジュール用のドキュメントは、いつできるのですか?

Avital: それは、もっと最終版に近いパッケージ APIのドキュメントの一部としてドキュメント化されます。それは作業中です(それは我々のGithubリポジトリにあるリンカーブランチ上で見られるでしょう)

INFOQ: 0.6.0に同梱されているエンジンパッケージ管理システムとは何ですか?なぜこれが前のイテレーションと違うのですか?

Avital: 我々は2つの大きな問題に取り組んでいました。(1)アプリがリリースに固定されるべきであり、理想的には、リリースを切り替えるときに、すべてのパッケージをダウンロードする必要はない、(2)Meteorは、サードパーティのパッケージをネイティブでサポートすべきです。これらの目標を達成するために、我々はMeteorコマンドラインツールとパッケージを別々にリリースします。リリースは、単にツールと、各パッケージのリビジョンを指します。新しいMeteorリリースを実行すると、我々は,変更された成果物を取得し、次に ~/.meteorで見つかるウェアハウスにキャッシュするだけです。

INFOQ: David Glasser氏があなた方はいつもNPMをサポートしたいと思っているが、「正しく」やりたいと思っている、と 最近、言っています。これはどういう意味か説明してくれますか?

Avital: 我々は絶対に人々に直接npmコマンドを走らせたいと思っていません。MongoDBのインスタンスを走らせたくないのと同じです。なので我々はnpm installなどを背後で走らせます。我々は、またnpm shrinkwrapを利用して、スマートパッケージを使えば、いつも同じコードが走るのを保証したいと思っています。これらのことを全てシームレスに成し遂げるには、我々はNPMを走らせるために、ある程度のことをやらなければなりませんでした。沢山の余計な細かな詳細があります。例えば、npm shrinkwrapでは1つだけの依存性を持つバージョンをアップグレードできない、という事実があります。とにかく、興味のある人は、これら全てを実装したコードがここにあるので見てください。

INFOQ: 慣例を物ともせず、難しい意思決定を行った理由は、なんですか? (独自のパッケージ管理システム 対 現状[素のNPM])

Avital: いつも1つの動機付け要因があります。ユーザーにとっての最高の体験です。

INFOQ: NPM サポートの次は何ですか?

Avital: バイナリ依存性のあるパッケージをサポートするためにまだ多くのことをしなければなりません。我々は、サーバー上で、全てのプラットフォームでそれらを構築します。そうなれば「meteor deploy」を使うと、例えあなたのマシンが異なるアーキテクチャ(例えばMac)で走っていても、それは動きます。これまで説明しましたように、我々は汎用的なラッパーも作って、ノードスタイルの非同期APIをコールバックオプションを持ったAPIに変換するのを簡単にします。

INFOQ: Meteor 1.0 は、どのくらい近づいてますか?

Avital:それは、そんなにすぐでもないし、遠い先でもありません。:)

 

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT