問題タブ [watchify]

npm 経由で watchify パッケージをインストールしようとしていますが、失敗しています。しばらくすると、コマンドは実行を停止します。この問題を解決する方法について何か考えはありますか? どうも

gulp ファイルは正常に動作しているようで、 app.jsファイルまたは sass ファイルに変更を加えると Watchify が動作します。gulpコマンドを実行すると、次のようになります。

問題は、これらの時間は私が最初に行ったときにしか表示されないということですgulp。コマンドを実行した後gulp、JS ファイルを変更してもビルド時間が表示されません。sass ファイルのビルド時間はわかりますが、JS のビルド時間はわかりません。前に言ったように、Watchify は機能しており、新しい出力ファイルが作成されていますが、私の端末には、どれくらいの時間がかかったかを示すフィードバックがありません。実際、JS の変更に関するメッセージはまったくありません。

これが私のgulpfileです。

私はbrowserifyを始めたばかりです。それが働いているとき、それは素晴らしいです。しかしrequire()... 一部のモジュールが機能していません (デフォルト)。

私はこのコードを持っています:

上記で。jQuery と gsap が動作し、インポートされます。しかし、ウェイポイントはそうではありません。ウェイポイントが含まれていると、次のエラーが表示されます。

これは、ランダムな他のモジュールでも発生します。

npmでインストールされたすべてのモジュール。

このページの browserify/watchify レシピの使用: https://github.com/gulpjs/gulp/blob/master/docs/recipes/fast-browserify-builds-with-watchify.md

同様のスタックオーバーフローの質問に触発されたいくつかの修正を試みましたが、今のところうまくいきません.

いくつかの回答は、責任があるかもしれないnpmのバグがある/あったことを示唆しています。その場合、私にできる信頼できることはありますか？

さらに情報を提供させていただきます。

私は、jQuery、React、およびSocketIOに依存する「中規模の」Typescriptアプリケーション（自明ではありませんが、エンタープライズレベルでもなく、数千行のように）を持っています-他の小さなライブラリの中でも。

私の現在のgulpfileはこれです：

すべてが期待どおりに機能しますが、watch タスクを使用するときのビルド時間は数秒かかります。奇妙なことに、スクリプトの再コンパイルが 500 ミリ秒 (「時間」イベントのイベント ハンドラー) 未満で発生したとタスクが報告しているのに、頭の中でカウントすると、3 ～ 4 秒後まで完了しません。 .

既存の TypeScript コードを貼り付ける前に、jQuery、React、Moment、および使用していたその他のライブラリをすばやくロード/バンドルしていたことに注意してください。このため、別のベンダー バンドルを使用しても速度が向上するとは思いません。また、ソースマップを書き出さなくてもパフォーマンスに影響はないようです。

browserify に切り替える前は、コンパイルに gulp-typescript を使用し、モジュールのロードに requirejs を使用していました。これらのビルドには 1 秒もかかりませんでした。ただし、requirejs は他の理由で問題を引き起こしていました。いずれにせよ、AMD から CommonJS に移行したいと考えています。

今のところ大きな懸念事項ではありませんが、プロジェクトが大きくなるにつれて、開発フローに問題が生じる可能性があります。これだけの規模のプロジェクトでは、これよりも大きなプロジェクトを処理するのにどれくらいの時間がかかりますか?

さらに、Visual Studio でも問題が発生しています。これは ASP.NET 5 アプリケーションであり、Visual Studioはバンドルされた JavaScript ファイルが変更されるたびに再ロード/再解析を要求しているようで、変更のたびに IDE で 1 ～ 2 秒の遅延が発生します。再コンパイル自体には 3 ～ 4 秒かかります。スクリプトは wwwroot フォルダーにレンダリングされており、ASP.NET 5 ツールを使用してスクリプト サブフォルダーを "除外" する方法はないようです。

私はどこかで何かが欠けていることを知っています。考えられる問題は、tsify が typescript の「プロジェクト」機能を使用してリロードを実装していないため、TypeScript コンパイラが変更ごとに各ファイルを再処理することです。

とにかく、おもちゃのプロジェクトを超えてこれらのツールを使用したのは私だけではないので、より良い解決策があるかどうかをここで尋ねています。この問題を除けば、すべてが非常にうまく機能しているためです。

編集 - - - - - - - - - - - - - - - -

わかりました、自分の言葉を食べなければなりません。サードパーティのライブラリを独自のバンドルにバンドルしているため、ビルドは約 1 秒に短縮されています。これが更新された gulpfile です (新しい dev.scripts.vendor タスクと buildScripts 関数の .external 呼び出しに注意してください)

しかし、私はまだ奇妙な問題を抱えています。ソースマップを無効にすると (現在は速度に影響があるようです)、 on("time", () => {}) コールバックはファイル変更ごとに 60 ～ 80 ミリ秒を報告していますが、それでも約 1 秒間ハングします。 . これを待つのは 1 秒程度なので、プロジェクトが大きくなるにつれて、この待ち時間も長くなる可能性があるのではないかと心配しています。

イベントがはるかに小さなものを報告しているときに、この追加の 1 秒が何に費やされているかを確認するのは興味深いことです。おそらく、誰もすぐに答えを持っていないように見えるので、ソースを少し掘り下げ始めます。

別の問題これは単なる補足ですが、 debowerifyはこれで機能しなくなりました。debowerify+bower を使用すると、そのモジュールが「外部」リストにリストされている場合でも、最終出力で必要なモジュールをレンダリングし続けます。したがって、現在この設定では、アプリ バンドルにコンパイル時間を追加しても問題ない場合を除き、npm モジュールしか使用できません。

また、debowerify は npm モジュールをオーバーライドし、bower 構成ファイルではなく、bower_components のディレクトリ リストに基づいていることを知りました。jQuery を npm にインストールし、Bower でのみブートストラップしました。しかし、ブートストラップが依存関係として jQuery をプルダウンしたため、bower jQuery モジュールが NPM jQuery よりも優先的に読み込まれていました。人々のために頭を上げてください。

一般的なワークフローは次のとおりです。

1. JSファイルを編集
2. ファイルを保存すると、watchify が自動的に再構築を開始します
3. ブラウザへのalt-tab
4. ctrl+Rでページをリロード

これは素晴らしいことですが、watchify がステップ 3 と 4 よりも時間がかかる場合を除いて、古いコードまたはエラーが発生するため、最悪です。

それが決して起こらないことを保証する簡単な方法はありますか? 要求されたページをロードしようとする前に、watchify がサーバーに別の瞬間を待つ必要があることを通知する方法のように? そのようなものが存在しない場合、人々は実際にこの問題にどのように対処しますか?

この問題について話している人を見つけることさえできないので、私はグーグルでしゃべる必要があります。ページをリロードしても、時計がまだ完全に動いていないことがわかるという現象です。」-- 残念ながら、それは todo リストのエントリであり、そのリポジトリに存在するものではありません。

Gulp や Grunt の使用を避けたい (他の誰かがそれらにうんざりしていませんか?)

の中へ

ファイルに入力できる1行のコマンドを使用しpackage.jsonます。

babel、babelify、browserify、およびwatchifyコマンドラインのバリエーションを試してみましたが、役に立ちませんでした。これが私が試したものの例です：

...そして、私が試した他の多くのバリエーションがあります。

更新 1 :

私は近くにいます。

これは機能しますが、への変更を検出しませんsrc/components/index.jsx。

更新 2 :

(大規模な) React ライブラリをバンドルから除外すると、すべてが機能します。

...これは、この GitHub の問題 で説明されているように、何かが静かにうまくいかず、watchify が壊れているのではないかと考えさせられます。