web-dev-qa-db-ja.com

クライアント側のJavaScript：サードパーティのフレームワークを含める方法は？

Webアプリを開発する場合、Twitterのブートストラップなどのいくつかのフレームワークの上にアプリを構築することがよくあります。これらのフレームワークにはless/sass/stylus、javascript、画像、場合によってはウェブフォント。

これらのフレームワークをアプリに埋め込む方法を知りたいです。ほとんどのアプリは、coffeescriptとstylusをそれぞれjavascriptにコンパイルするいくつかの不快なタスクを使用してビルドされていますcss。アプリにサードパーティのコード（フレームワークなど）を同梱していないため、依存関係として追加します。これにより、たとえば、 npmやvoloなどのパッケージマネージャーを使用するフレームワーク。

小さなJavaScriptライブラリ（これはoneファイルのみで構成され、アセットはありません）の処理は簡単です。それらをベンダーディレクトリにインストールし、require.js confを更新します。ただし、ライブラリに画像またはless/sass/stylus/css添付ファイル私は常にそれらを処理する方法に苦労しています：

  • これらのライブラリのcssファイルまたはjavascriptファイル内のアセットへのパスは、多くの場合、ハードコードされています（相対）。
  • less/sass/stylusはコンパイルする必要があります（これはひどいタスクで実行できます）
  • すべてのサードパーティアセットをフォルダ構造にコピーしますか？
  • サードパーティのアセット（stylesheets、javascript）を自分のファイルに含めて、一緒に最小化する必要がありますか？
  • stylusを使用し、フレームワークがsassを使用する場合、さらに多くの依存関係をインストールする必要があります

これらの問題を抱えているのは私だけではないので、解決策、ベストプラクティス、または一般的なヒントを探しています。

web-developmentjavascriptframeworksorganization
6
cr0

これらのフレームワークをアプリに埋め込む方法を知りたいです。

短い答え：

エイリアスを使用しますか？

自動化できれば、コピーによる害はありません。

長い答え：

以下のリストは、私が使用するツールとテクニックの一部です。

バウアー

BowerはWeb用のパッケージマネージャーです。これは、フロントエンドパッケージ管理の問題に対する一般的な解決策を提供し、APIを介してパッケージ依存モデルを公開します。より独断的なビルドスタック。システム全体の依存関係はなく、依存関係は異なるアプリ間で共有されておらず、依存関係ツリーはフラットです。

Grunt.js

Grunt：JavaScriptタスクランナー。

grunt-bower-task

Bowerパッケージをインストールします。スマートに。

...言及する価値もあります：

Gitサブモジュール

サブモジュールを使用すると、Gitリポジトリを別のGitリポジトリのサブディレクトリとして保持できます。

実世界の例...

Gruntfile.js内に、bowerタスクがあります。

bower : {

    install : {

        options : {

            targetDir : './files/plugins', // A directory where you want to keep your Bower packages.
            cleanup : true,                // Will clean target and bower directories.
            layout : 'byComponent',        // Folder structure type.
            verbose : true,                // Debug output.

        },

    },

},

...上記にはbower.jsonが必要です（Gruntfileの横に）：

{
  "name": "simple-bower",
  "version": "0.0.0",
  "dependencies": {
    "normalize-css": "2.1.3",
    "foo": "https://github.com/baz/foo.git"
  },
  "exportsOverride": {
    "foo": {
      "scss": "foo/scss/",
      "css": "foo/*.css"
    }
  }
}

上記のbowerタスクを実行すると、次のようなフォルダー構造が得られます（「コンポーネント」で構成）。

  • plugins/
    • normalize-css/（コンポーネント）
      • normalize.css
    • foo/（コンポーネント）
      • css/
        • foo.css
        • foo.min.css
      • scss/
        • foo.scss
        • partials/
          • _variables.scss
          • _functions.scss
          • _mixins.scss
          • _other.scss

注：exportsOverrideオプションを使用して、エンドポイント（この場合は、main）を介して指定されたfooリソース以外のリソースを「取得」できましたbower.json。

上記の設定に基づいて、plugins/というフォルダー（vendor/フォルダーなど）ができました。これで、Gruntfileタスクを上記のディレクトリやファイルにポイントできます。

しかし、ライブラリに画像またはそれ以下/ sass/stylus/cssファイルが添付されている場合、私は常にそれらの処理方法に苦労しています...

エイリアステクニック＃1：

質問：上記のBowerのインストールに基づいて、normalize.cssを SASS部分 ？としてどのように含めますか？

1つの解決策は、エイリアスを作成することです（cwd =プロジェクトのscss/フォルダ）：

$ ln -s ../plugins/normalize-css/normalize.css _normalize.scss

そこから、エイリアスをSCSSパーシャルとして扱い、@importをscssファイルに自由に入れることができます。

エイリアステクニック＃2：

質問：上記のBowerのインストールに基づいて、fooのscssパーシャルをどのように含めますか？

foo.scssにすべてのパーシャルが含まれていると仮定すると、@importsは相対であるため、ダイレクトエイリアスとしては機能しません。

では、なぜフォルダ全体をエイリアスしないのですか？

$ ln -s ../plugins/foo/scss ./foo

これで、サードパーティの依存関係のscssパーシャル（または単にfoo.scss）をプロジェクトのビルドプロセスに簡単に含めることができます。脚の作業はそれほど必要ありません。

コピーテクニック...

すべてのサードパーティアセットをフォルダ構造にコピーしますか？

このアプローチでも問題はありません。最適には、次のようなタスクでコピーを自動化します。

grunt-contrib-copy

1つのアプローチは、copyタスクを介して実行するinitターゲットであり、ビルドディレクトリで指定した場所にソースファイルをコピーします。そこから、通常と同じように、その他の/プロセスタスクを実行して、開発/プロダクションファイルを生成/ビルド/コピーします。

これが私の最新プロジェクトの1つからのコピータスクです。

copy : {

    // Copies `normalize.css` from `plugins/` into the root-level `/demo/` folder:
    dev : {

        filter : 'isFile',
        expand : true,
        cwd : './files/plugins/',
        src : '**',
        dest : '../demo/',
        flatten: true,

    },

    // Copies source `scss` files into my distribution folder:
    prod : {

        filter : 'isFile',
        expand : true,
        cwd : './files/styles/',
        src : [
            '**/*',
            '!demo.scss',
        ],
        dest : '../<%= pkg.name %>/scss/',

    },

    // Copies images into the root-level `/demo/` folder:
    all : {

        expand : true,
        cwd : './files/images/',
        src : '**',
        dest : '../demo/',

    },

},

直接リンク手法？

必要に応じて、vendor/フォルダー内のサードパーティのアセットに比較的リンクすることはそれほど難しくありません。直接のリンクが機能しない場合（ある種の相対的なインポートなどが原因で）、上記の2つのエイリアスオプションが適切な代替手段になります。個人的には、パスの文字列をきれいに保つため、エイリアスがいいと思います。

最小化または醜化しますか？

自分のファイルにサードパーティのアセット（スタイルシート、JavaScript）を含め、それらを一緒に最小化する必要がありますか？

私は、実稼働環境では間違いなくはいと言います。

私の個人的なアプローチは、「dev」と「prod」の2つのビルドプロセスを持つことです。前者はソースファイルにリンクし、後者はmin/uglifiedファイルにリンクします。

ここでは、ビルドプロセスの基本的な概要を説明しました。

さまざまな設定に対してGruntにindex.htmlを生成させる

私にとっての目標は、開発用の「dev」ビルド（バグを探すのに簡単に使用できる）と本番用の「prod」ビルド（ソースファイルが更新されたときに新しいバグが発生する可能性があることに注意してください）を持つことです。結合/縮小/醜化された）。

私が定期的に使用するグラントタスクで、最小/醜いファイルを生成します。

  1. grunt-contrib-jshint
  2. grunt-contrib-uglify
  3. grunt-contrib-sass
  4. grunt-contrib-less
  5. grunt-contrib-htmlmin

注：私は常に、ビルドにサードパーティのコードの非縮小/醜化バージョンを含めるように努めています。既に圧縮されたファイルを使用する場合は、ビルドプロセスで（これらのファイルの）圧縮手順をスキップし、代わりにファイルの連結を行います。

サードパーティは別のプリプロセッサ/その他を使用していますか？

スタイラスを使用し、フレームワークがsassを使用する場合、さらに多くの依存関係をインストールする必要があります。

それは間違いなく窮地です。私が考えることができるいくつかの解決策：

  1. これらの不測の事態に備えるだけです。通常、パッケージをインストールするのはそれほど難しくありません（ homebrew が役立ちます）。したがって、システムがセットアップされると、次にこのタイプの状況に遭遇したときに簡単になります。そこから、ソースファイルをビルドに組み込むGruntタスクを見つけるのは難しくありません。多くの場合、temp/フォルダを使用して「中間」のビルドファイルを格納し、次に他のタスクを使用して、上記のコードを他のコードと結合/縮小/醜くします（たとえば、 sass/lessで生成されたファイルを結合するには... /tempにスラップして、ビルドプロセスのある時点で結合します）。

  2. 好みのツールを使用しているフレームワークのバージョンを見つけてください。たとえば、TwitterのBootstrapはlessを使用していますが、幸いなことに sass version があります。問題は（うまくいけば）解決しました:)

  3. それが存在し、それを回避できる場合は、フレームワークの「生成された」バージョンを使用します。たとえば、作成したプロジェクトごとに生成されたソースファイルを含めようとします...あなたについては知りませんが、既に生成されたバージョンのプラグインを表示/使用するオプションがあり、特にそのプラグインがうまく機能する場合は-私のプロジェクトではすぐに使える。

  4. その他？私は現在これについてのアイデアがありません。

そうは言っても、私は決してこのトピックについての権威ではありません...上記は私にとってうまくいくものです。このことに関しては、個人的な好みとして、単純なものと複雑なもののバランスをとることがあります。

4
mhulse

一般向けのWebサイトでこのようなことをしているのであれば、可能であれば誰かのCDNを使用する方法を検討します。おそらく、サイトがより高速になり（CDNがゼロに近づいている場合）、独自のサーバーに使用する帯域幅が少なくなります。彼らはコンテンツの有効期限を適切に設定し、適切にキャッシュする必要があります。

ただし、それが内部アプリの場合は、サードパーティのCDNに依存したくない場合があります。これにより、インターネット接続が切断された場合でもアプリが機能し続けることができます。または、インターネット接続が危険な場合は、アプリの信頼性が向上します。この場合、すべてをダウンロードし、それを縮小してバンドルします（妥当な範囲で）。

他の懸念事項に答えるには：

  • これらのライブラリのcssファイルまたはjavascriptファイル内のアセットへのパスは、多くの場合、ハードコードされています（相対）。

ええ、それは苦痛です、あなたはどういうわけかそれを扱わなければならないでしょう。私はASP.NETのバンドルと縮小（System.Web.Optimization）を使用しています。これにより、CSSおよびJavaScript内からの相対パスが機能するようにベースURLを設定できます。

  • less/sass/stylusをコンパイルする必要があります（これはひどいタスクで実行できます）

私はそれらのいずれも使用していませんが、カバーされているようです。

  • スタイラスを使用し、フレームワークがsassを使用する場合、さらに多くの依存関係をインストールする必要があります

うん、それはフレームワーク、特に依存関係のあるフレームワークを使用することのトレードオフの1つです。それを使用することの利点がそれを管理する苦痛を上回ると考えるなら、それはあなたの呼びかけです。

1
Rocklan