Meteor Development Groupは、Meteor 0.6.0を４月４日にリリースした。これはそのパッケージ管理に対するオーバーホールと成長し続けるNPMパッケージへのサポートである。それからバージョン 0.6.2が４月１６日にリリースされ、継続的な改善とバグ修正が行われた。
それが 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に対しての批判の１つが「プロプライエタリなパッケージシステム」でした。 Meteor 0.6.0は、この話を変えますか？
Avital:まあ、私は何でスマートパッケージがNPM, Bower, Component,そして他のもっと知られていないパッケージ管理より、もっと「プロプライエタリ」になるのかわかりません。スマートパッケージは、NPMモジュールでは「ありません」、例えば。 スマートパッケージのユニークな特性の１つが、クライアント、サーバー上で、ビルド中に、運用環境にさえフックして、走ることです。このおかげで
meteor add coffeescript,meteor add appcache、meteor add emailとするだけで機能するのです。Geoff Schmidt [Meteorのコア開発者の一人] 氏がこれらの差について短いエッセイを書いてます。
INFOQ: 様々な種類のNPMパッケージの中で、NPM.dependを介するMeteorラッピングで「手の届くもの」はどれですか？ Meteor内部のNPM名前空間は、NPMの機能に追加のラッピングを行う（非同期プロセスは、Futureにロールアップされていることを保証する、など）か、それは、NPM-Meteorラッパーのジョブですか？
Avital: 確かに
Future.wrapのようなある種の汎用的なラッパーを作りますがもっといいものです。Future.wrapによっていくつかのエッジケースを回避できますし、コールバックオプションのあるインターフェースを提供します。例えば、サーバー側のMeteor.callとMeteor.http.callです。当面は、future.resolver()を使うのが最も簡単なやり方です（XML2JS exampleにあるようにです)。どのNPMモジュールをラップするかに関してですが。 皆さんが使いたいと思うものをラップします、と言うだけです。そうすることで、コミュニティが必要とするMeteorのツールを使う助けとなるでしょう。それによってまた、我々がどの機能に我々の工数を当てるべきかがわかります。
INFOQ: NPMモジュール用のドキュメントは、いつできるのですか？
Avital: それは、もっと最終版に近いパッケージ APIのドキュメントの一部としてドキュメント化されます。それは作業中です(それは我々のGithubリポジトリにあるリンカーブランチ上で見られるでしょう)
INFOQ: 0.6.0に同梱されているエンジンパッケージ管理システムとは何ですか？なぜこれが前のイテレーションと違うのですか？
Avital: 我々は２つの大きな問題に取り組んでいました。（1）アプリがリリースに固定されるべきであり、理想的には、リリースを切り替えるときに、すべてのパッケージをダウンロードする必要はない、（2）Meteorは、サードパーティのパッケージをネイティブでサポートすべきです。これらの目標を達成するために、我々はMeteorコマンドラインツールとパッケージを別々にリリースします。リリースは、単にツールと、各パッケージのリビジョンを指します。新しいMeteorリリースを実行すると、我々は,変更された成果物を取得し、次に ~/.meteorで見つかるウェアハウスにキャッシュするだけです。
INFOQ: David Glasser氏があなた方はいつもNPMをサポートしたいと思っているが、「正しく」やりたいと思っている、と 最近、言っています。これはどういう意味か説明してくれますか？
Avital: 我々は絶対に人々に直接npmコマンドを走らせたいと思っていません。MongoDBのインスタンスを走らせたくないのと同じです。なので我々は
npm installなどを背後で走らせます。我々は、またnpm shrinkwrapを利用して、スマートパッケージを使えば、いつも同じコードが走るのを保証したいと思っています。これらのことを全てシームレスに成し遂げるには、我々はNPMを走らせるために、ある程度のことをやらなければなりませんでした。沢山の余計な細かな詳細があります。例えば、npm shrinkwrapでは１つだけの依存性を持つバージョンをアップグレードできない、という事実があります。とにかく、興味のある人は、これら全てを実装したコードがここにあるので見てください。
INFOQ: 慣例を物ともせず、難しい意思決定を行った理由は、なんですか？ （独自のパッケージ管理システム 対 現状[素のNPM])
Avital: いつも１つの動機付け要因があります。ユーザーにとっての最高の体験です。
INFOQ: NPM サポートの次は何ですか？
Avital: バイナリ依存性のあるパッケージをサポートするためにまだ多くのことをしなければなりません。我々は、サーバー上で、全てのプラットフォームでそれらを構築します。そうなれば「meteor deploy」を使うと、例えあなたのマシンが異なるアーキテクチャ（例えばMac）で走っていても、それは動きます。これまで説明しましたように、我々は汎用的なラッパーも作って、ノードスタイルの非同期APIをコールバックオプションを持ったAPIに変換するのを簡単にします。
INFOQ: Meteor 1.0 は、どのくらい近づいてますか？
Avital:それは、そんなにすぐでもないし、遠い先でもありません。:)