TARSを使用したフロントエンドの開発でさらに快適に

TARSに関する最新ニュース（ 1回と2回 ）から次の6か月が経過しました。つまり、最新ニュースを共有する時です。 いつものように、TARSはGulpベースのフロントエンドビルダーであり、フロントエンド開発者やチーム全体が複雑なプロジェクトを作成するのに役立つことを思い出します。 私たちはロシアだけでなく、自信を持って行進を続けています。 TARSは、オランダ、日本、中国、ウクライナ、ポーランドなどですでに使用されています。 これは、 GitHubの星の数、 gitterのチャット参加者の数、および先月（1,000以上、ピーク時は3000以上）のTARS-CLIインストール数の両方で確認できます。 ほぼ200件の問題をクローズし、2つの主要なアップデートをリリースしました。 コレクターユーザーは積極的に報告し、開発に参加します。 小さなコミュニティがあると言えます。

大きな変更

TARSは、予約なしで、本当にモジュール化されました。 打ち上げと組み立ての速度が大幅に向上しました。 最も重要な変更には、プロジェクトのwebpackと自動更新（コレクターのバージョンの更新、ブラウザーでの再起動ではない）が含まれます。



最後に、ファイルを連結するだけでなくJavaScriptを構築できます。 2016年にTARSでのスクリプトのビルドが非常に遅れていたことは残念でさえありました。 WebpackはJavaScriptで解放されました。 すぐに使用できるTARSでもサポートされているHot Module Replacementは 、驚くほど機能します。 また、ブラウザ同期のスタイルのinjectChangesオプションを使用すると、開発は素晴らしいものになります。ブラウザは再起動しませんが、その場でCSSと、可能であればJavaScriptの変更を適用します。 さらに進むと、スタイルとテンプレートの作業をwebpackに移行できます。 TARSのタスクは簡単に再定義できるようになったため、CSSとテンプレートの責任の移転はwebpackを使用して簡単に実装できます。 JavaScriptの構築のみを説明する場合、webpackは多くの機能を提供します。これらの機能はドキュメントで読みやすくなっています。 さらに、2番目のバージョン（ベータテスト段階）から、 Tree shakeが登場しました。これにより、モジュールで実際に使用されているコードのみをアプリケーションの各ポイントにインポートできます。



webpackがプロジェクトに入ってくると、すべてがwebpackとnpmスクリプトで実行できる場合、Gulpが必要な理由を尋ねることができますか？ ここでの答えは非常に簡単です。Gulpを使用すると、すべてがはるかに簡単になります。



実際、webpackについては疑問がありません。TARSでは、テンプレートをコンパイルしてCSSを構築し、対応するローダーを使用するタスクをオフにするだけです。 したがって、質問を別の方法で言い換える価値があります。その機能がnpmスクリプトを実行できるのに、Gulpの形式で何らかの抽象化が必要なのはなぜですか？

npmの完全なパワーと利点を説明する多くの記事がすでに書かれています。 最も説得力のある議論に答えようとします。 すぐに明らかにする価値があると思います。多くのタスクがあり、それらの間に実行順序に依存関係がある場合について話しています。



最初に、タスクを連続して並行して起動する独自の実装を作成する必要があります。 これを完璧に行うことができるGulpがある場合、なぜですか？ さらに、特定のファイルセットを処理するときにストリームを操作すると便利な場合があります。 そのような機能を自分で記述するか、単に破棄する必要があります。



npmスクリプトへの切り替えを支持する深刻な議論は、Gulpのプラグインサポートが不十分であるということです。 UglifyJS、PostCSSなどのさまざまなモジュールのラッパーであるgulpプラグインについて説明しています。 当然、たとえばUglifyJSの更新とgulp-uglifyの間にわずかな「遅れ」があるかもしれませんが、多くの場合、それは必須ではありません。 Gulpプラグインの作成者と、このプラグインが作成されたパッケージが1人であることがよくあります。 誰かが開発を単純に放棄することも可能です。 この場合、作成者の開発を続けるか、gulpラッパーなしでパッケージを直接使用できます。 したがって、TARSのwebpackは機能します。



そして最後に、package.jsonの長いフットクロスよりもタスクの操作がはるかに快適です。 もちろん、いくつかのタスクしかないプロジェクトでは、フットクロスはほとんど不可能です。 TARSの場合、1つのツールで可能な限り多くの開発者のニーズをカバーしようとしており、タスクの順次実行と並列実行の間に複雑な依存関係がある場合、npm-scriptsの使用は正当化されず、スティックをホイールに挿入します。



Gulpは非常に使いやすいもので、さまざまなプラットフォームでさまざまな環境でテストされています。 使用可能なAPIメソッドは4つだけで、並列および順次タスク起動用の複雑なスクリプトを作成できます。 最終的には、TARSが機能するだけなので、Gulpが内部にあることを知る必要さえありません。



Webpackサポートが多くのプロジェクトで長い間実装されている場合（およびビルダーがwebpackのみでビルドされている場合）、誰もプロジェクトの自動更新などの機能を提供しません。 TARSを使用すると、Webサイト/サービス/他の何かを安全に開発し、1つのチームですべての最新のTARS機能を取得できます。 この場合、すべての設定、プロジェクトファイル、ユーザータスク、ウォッチャーが保存されます。 昨日、JavaScriptファイルを連結し、今日、プロジェクトを更新して、webpackを使用する機会を得ました。 すべての更新手順が記録されます。さらに、プロジェクトの更新時に起動される独自のチームを追加する機会があります。



次はそれほど重要ではありませんが、それほど有用な変更はありません。

有用なささいなこと

ESLintはJSCSとJSHintを置き換えました。 ところで、最近JSCSプロジェクトのメンテナーであるMarat Dulin は、JSLCチームをESLintプロジェクトに移行することを発表しました 。 したがって、まだESLintを使用していない場合は、始めましょう。 コード検証ははるかに速く通過し始めました。設定を操作すると便利です。一般的には、あらゆる側面からの利便性です。



TARSおよびTARS-CLIコードは、ES6で徹底的にリファクタリングおよび書き直されました（NodeJSバージョン4で使用可能な機能のサポート付き）。 一般に、すべてがより明確になり、理解しやすくなりました。この点に関しては、プルリクエストが増えることを願っています。 メインのgulpfileは30行しかないため、目を楽しませています。 コードはES6で記述されているため、4以下のNodeJSバージョンのサポートを放棄しなければなりませんでした。ドキュメントが更新され、多くのタイプミス、エラーなどが修正されました。



SVG文字を使用する機能が追加されました。 同時に、既製の文字のスプライトを接続するオプションを選択することができます：各ページの本文にスプライトコードを挿入し、すべての文字を個別のファイルに保持し、接続するときにこのファイルへのパスを（自然に、自動的に）指定するか、文字を含むファイルをアップロードします。



モジュールはコンポーネントに名前が変更されました。 この場合、新しい名前が気に入らない場合は、構成でコンポーネント/モジュールを含むフォルダーの名前を構成できます。 これで、コンポーネントをコンポーネントに挿入できます。 この機能は、CLIユーティリティでもサポートされています。



CLIを使用してカスタムコンポーネントを作成するための多くの要求がありました。 あなたが尋ねた-私たちはやった！ これで、jsonファイルでコンポーネント図を記述でき、好きなだけスキームを作成できます。



TARSで使用されるほとんどすべてのプラグインは、1つの共通の構成ファイルで便利に構成できます。



自動連結ではなく、最終アセンブリで必要なもののみをインポートできるエントリポイントを使用して、スタイルをコンパイルする機能を実装しました。 これにより、スタイルの操作の自由度が高まることを期待しています。



Jadeテンプレートの再構築を大幅に加速しました。 ここで、可能なすべてをキャッシュし、この段階で本当に必要なものだけを再コンパイルします。



そして最も重要なことは、次のコマンドを実行するだけで、これらすべてのイノベーションを取得できることです。

tars update-project
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

プロジェクトは、すべての設定が保存された最新バージョンに自動的に更新されます。

今後の計画

TARSの開発は止まりません。まだ実装したいことがたくさんあります。

• ベータテストを終了するとき、最終的にGulpのバージョン4に切り替えます。
• ベータテストを終了したら、webpackの2番目のバージョンに切り替えます。
• JavaScriptコレクターとして[Rollup]（https://github.com/rollup/rollup）の使用を有効にします。
• TARSプラグインのインフラストラクチャを作成します。 プラグインシステム-「狭い」タスクを解決するために必要なTARSへのさまざまな追加。 最も簡単な例は、文字を植字するタスクです。 「tars install tars-email」と入力するだけで、電子メールのレイアウトで快適に作業できるように、ローカルのTARSにタスクが追加されると想像してください。
• プリプロセッサなしでPostCSSを使用する機能を実装します。
• cssモジュールのサポートを実装します。
• 最終的にプロモーションサイトを完成させます。
• TARSおよびTARS-CLIのテストをさらに作成します。

現在、TARSは以前のバージョンとの互換性を損なうことなく開発されています。そのため、エンティティは新しいバージョンのままであり、削除してもよいでしょう。 この互換性を壊して、次のバージョンで余分なものがなくなるようにします。 少なくとも半自動で1.xxから2.xxに更新するメカニズムを実装してください



さらなる計画については、 githubでフォローアップしてください。 そこでプロジェクトに影響を与えることができます。 私たちは常に新しいアイデアを喜んでいます。 gitterに書き込み、電子メールtars.builder@gmail.com近い将来、SlackやTelegramにチャンネルが表示される可能性があります。