KevinさんのDenoパッケージについての考え
このスレッドの話をちょっと日本語訳(google先生による)。
文脈としては、kt3kさんとdenolibやregistryについての立ち位置について話していたところに、コアメンバーのkevinさんがコメントしてくれたというもの。翻訳で読んでくれてるのかな。hashrock.icon
Yeah I created the org more or less to differentiate from denoland, which should be treated as official (especially deno_std, Ryan is planning to merge it with deno main repo some day). I deem denolib as a place to host community created repos, libs and documentations.
ええ、私は多少なりとも公式として扱われるべき denolandと区別するためにOrganizationを作成しました(特にdeno_stdについては、Ryanはいつかそれをdenoのmainリポジトリとマージすることを計画しています)。
私は denolibをコミュニティが作成したレポジトリ、ライブラリ、ドキュメンテーションをホストする場所と見なしています。
deno_std、本体にマージするのか~!また大胆な…hashrock.icon
I would say http://deno.land/x is not likely host npm pkgs that are ported automatically (such as using webpack). Otherwise should be fine. For example, deno_std/path is manually ported from Browserify’s path-browserify, with proper type annotation added and using deno API それ以外の場合は大丈夫です。たとえば、deno_std / pathはBrowserifyのpath-browserifyから手動で移植され、適切な型注釈が追加され、deno APIを使用しています。
Webpackを使ってポーティングするというのはnode-to-denoの方式だと思うけど、そんな感じで雑に一括変換するような流れになると見ているのかな?hashrock.icon
手作業でのポーティングで、ある程度安定しているrepoはregistoryに送ってOKとのことhashrock.icon
Also, I feel the current registry is still more or less a prototype. Personally I would prefer developing packages somewhere else (or place inside denolib) and submit to registry/deno_std when I am confident with basic code stability...
また、私は現在のレジストリがまだ多かれ少なかれプロトタイプであると感じています。
個人的には、どこか他の場所(またはdenolibの中)でパッケージを開発し、コードの安定性に自信がある場合にはregistry / deno_stdに送信するようにするのがいいと思います。
registryは確かになくなったり仕様変更されそうな気はするhashrock.icon
denolibに参加者が増えるといいかなとは思っている。hashrock.icon
自信作ができたら、個人で抱えるよりは、denolib下でホストしてもらったほうがいい気もするhashrock.icon
The logging and colors packages are both originally hosted by the contributors themselves, only recently are they moved to deno_std
loggingとcolorsパッケージは、どちらも元々寄稿者自身によってホストされていましたが、ごく最近になってdeno_stdに移動します