Revert 'require' word optimization

オープン
  • 何か問題がありますか？
#63 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
35/100
issue の種類
リファクタリング
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
javascript
領域
tooling

調査の方向性

まず、issue で議論されている regex の最適化を見つけ、それが syntax-error とどのように関係しているかを追跡します。参照されている browserify の issue を読み、そこで言及されている sm-fast ブランチと比較します。最適化が syntax-error の upstream での削除をサポートする形で元に戻され、プロジェクトの既存のチェックも引き続き通過すれば完了です。

索引モデルが issue の本文から書いたものです。

説明

@zertosh What do you think about reverting the regex optimization so that syntax-error can be removed upstream?

Giant libraries with no require calls should be noParse'd anyway, and the performance difference, while significant, is only really marginal. Whereas the performance difference gleaned by removing syntax-error upstream is asymptotic and enormous.

IMO the bundle time of incremental re-builds is more important than one off full rebuilds, since incrementals are executed constantly (and also could be cached by browserify-incremental if you wanted).

I'm requesting this per your comment in this thread:

https://github.com/substack/node-browserify/issues/1208#issuecomment-92146245

If you did this and merged in your sm-fast branch, we could have really awesome rebuild times I think.

主要言語
JavaScript
スター
414
フォーク
59
30日以内にマージされた PR はありません

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

browserify/detective のほかの issue

browserify/detective の issue をすべて見る

似ている issue

JavaScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。