Roma-Facebookツールチェーンが大まかです.

何がロマですか
romaは、中国語名 Facebookのrnチームの出力であり、テスト性質のjavascriptツールチェーンであり、コンパイル、linter、フォーマット、包装、テストなどが一体となります.ターゲットはJavascriptソースコードを処理するための包括的なツールになることです.
romaは既存のツールを収集する統合体ではなく、すべての内部部品は業務によって徐々に精製され、三方倉庫を使用していません.
ロマはテストツールですが、現在積極的に発展しています.現在興味のある未来貢献者たちは門を開けています.ロマはまだ生産環境で使う準備ができていないので、ロマを使う唯一の方法はソースコードから構築することです.
romaは、多くの既存のjavascriptツールの代わりになるかもしれません.もちろん、将来は他のツールでも使えるコンポーネントを提供します.例えばromaをプラグインとして他の荷造り器に集積する.
ロマはMITプロトコルに従い、Conttributor Covent Code of Coductに基づいて管理します.
ロマの誕生
Sebastian McKenzieからスタートしたromaプロジェクトは、Babelとyarnの作者でもあります.
romaはFacebookのrnチームが力を合わせて完成したプロジェクトです.
ロマの名前からインスピレーションを受けたのは 、 と .これらはromaに対する期待を代弁して、全体のプロジェクトの中で広い適応範囲と私達の約束(一致性)に対する渇望があることを望みます.しかし.romaという野心的なプロジェクトは事務室の冗談から始まった.
ロマにはスパルタヘルメットのロゴがあります.ロマとは関係がないかもしれませんが、Galeaよりずっとかっこいいです.
コードライブラリ
romaはほとんど完全にtypescriptを使って書かれていて、緩いタイプはほとんどありません.
romaはmomonopo仕様構造を採用しています.
romaは完全にホストして、更新するたびに前のバージョンを使って新しいコードをコンパイルします.
romaはJSXとFlow、Typeescript特有のコメントコードをサポートしています.
詳細を見る
現在の焦点
現在私達は主にlintingの部分に力を尽くしています.issueを参照してください.
手っ取り早い
プロジェクトの中でromaを集めたいなら、あなたがするのは1つの構成ファイルだけです.roma.json

$ mkdir hello-world
$ cd hello-world
$ echo '{}' >rome.json

このファイルはromaを配置するために使用され、またromaホステルによって区別されるかどうかの重要なフラグでもある.
詳細は公式サイトをご覧ください.
ロマの哲学
以下のリストには、roma信守の精神が記載されています.これらの内容は全面的ではありません.いくつかは分かりやすいですが、完成性のためにまだリストされています.
プロジェクト管理

明確な目標を設定する:事前に工事の意図と期待を制定して、私達の工事は私達に意外な喜びを与えるべきではない!

公開性:romaに関する議論と決定は、github、roma dicord、ツイッターのような公共の場面で行われます.唯一の例外はコードの審査に対して私達は厳格に秘密を守ります.

技術

外部依存性がない:私たちはより機密的に内部ツールと抽象概念を統合することによって、プロジェクトの進捗とより一貫性のある体験を教えてくれます.カスタマイズ型を利用して、より良い体験をする機会がもっと多いです.

エラーに対して復旧のヒントを提供する:よくある使用方法の推論とフィルタリングを通じて、関係のない、助けのない提示情報を減らす.

エラー情報については、共通のエラー情報がありません.なぜエラーが発生したのか、開発者が間違った情報を使って位置を特定することができないからです.

APIを簡略化する:オプション設定とコマンドラインパラメータについては必須ではないと思う.彼らはうまく組み合わせて使うことができません.なぜ私たちはこの部分を簡単にできないですか?

専用用語を避ける:これらの専門用語はXを装う以外にはほとんど効果がないので、新人や専門家が一目瞭然になるように努力しています.例えば、コンパイルが間違った時に、「character」を使って「token」の代わりにします.

コマンドやコマンドラインのパラメータ回避の略語:必要がない時は迷いますが、文書を見なければならない略語を使います.

フォールトトレランス率が高い用語:分かりやすい用語を使う

対応端末のほとんど:terminalだけで使用すると仮定しないで、より多くの汎用環境に対応してください.

強いタイプを使う:緩いタイプを使わず、できるだけ検証入力する.

端末からの出力がより明確である:設計端末が出力する場合、色だけで読み取り可能性を高めるのではなく、フォーマット、記号、間隔を適切に運用して読み取り可能性を高める.

コミュニティ
貢献と開発の紹介はここです.
ここに来て一緒に討論してもいいですが、私達の基準を守ってください.