15

大量の .js ファイルを取得し、それらを次のようなグループに分類するのがあなたの仕事だとしましょう:

  • 少なくとも JavaScript 1.85 が必要です
  • 少なくとも E4X (ECMAScript 4 EX) が必要です
  • 少なくとも ECMAScript 5 が必要です

またはこのようなもの。

どんなソリューションにも興味がありますが、特に JavaScript や PHP を使用して機能するソリューションに興味があります。これは自動化された仕様の作成に使用されますが、問題ではありません - これは簡単に解決できるはずの素晴らしいタスクです - しかし、私には方法がわかりませんし、簡単ではありません。これが簡単な場合は、ヒントを共有してください。

http://kangax.github.com/es5-compat-table/#のようなものを期待していますが、ブラウザー用ではなく、特定のファイルを JavaScript のさまざまな実装に対してチェックするためのものです。

私の推測では、各バージョンには、テストできる特定の仕様が必要です。ただし、「このブラウザがサポートしているバージョン」に関する情報しか見つかりません。

PS: 「今はあなたの仕事です」を文字通りに解釈しないでください。私はそれをタスクを示すために使用しました。これを解決する過程で、助けや指示があればいいのですが。

編集:私は、私のプロジェクトが意図して期待どおりに機能するために、ECMAScript 5が現在のFireFoxと少なくとも同じくらいサポートされることを要求することにより、簡単な方法を取りました。

ただし、私はまだ解決策の試み、または少なくとも「可能です（XYで）」または「...のため不可能です」という明確な答えに興味があります。XY は、FrameworkXY や DesignPatternXY などのキーワード、またはもちろんより詳細なソリューションのようなものです。

4

2 に答える 2

3

基本的に、JavaScript ファイルの最小要件を見つけようとしています。実行時までそれは不可能だと思います。JavaScript は動的言語です。そのため、コンパイル時のエラーはありません。その結果、何かがうまくいかないことは何らかの閉鎖に入るまでわかりません。実際、依存関係によって多くの互換性の問題が解決される可能性があります。

例：

  • JS ファイル A はいくつかの ES5 機能を使用しています
  • JS ファイル B は、ES5 に欠陥のあるブラウザーにシムを提供するか、少なくとも何らかの方法でそれを模倣します。
  • JS ファイル A と B は常に一緒に読み込まれますが、A だけでは機能しないようです。

例 2:

  • Object.create はテストしたいものです
  • Crockford という名前の人が create を Object.prototype に追加します
  • Object.create は、互換性の低いブラウザーでも動作するようになり、何も壊れていません。

解決策 1:

  1. 依存関係マップを作成または検索します。明示的に、または HTML ファイルを反復処理して生成することができるかのいずれかで、確実に既に依存関係マップを持っています。
  2. 関連するすべてのコード パスを、機能が低下している環境で実行します (例: ES5、次に E4X、次に JS 1.x など)。
  3. あるコード パスで JS ファイルのバンドルが失敗すると、それらの最小要件がわかります。
  4. おそらく、オブジェクトのパブリック関数を繰り返し処理し、依存性注入を使用してコンストラクターとメソッドを埋めることができます。しかし、これは本当に難しいように聞こえます。

解決策 2:

  1. webdriverを使用して、さまざまな環境でページにアクセスします。
  2. window.onerrorアクションの実行中に現在のページが壊れたかどうかを通知する関数にマップします。
  3. エラーが発生すると、現在のページのバンドルに問題があることがわかるので、そのデータを保存します。

これらのソリューションは両方とも、常にエラーのない完璧な JS を作成することを前提としています。これは努力すべきことですが、現実的ではありません。これは可能性があります。ただし、いくつかの基本的な「煙テスト」を提供します。

于 2013-03-18T22:59:54.403 に答える
2

これは正確な方法では不可能であり、この種の問題について物事を見るのに最適な方法でもありません.

なぜそれが不可能なのか

Javascript には静的型付けがありません。ただし、プロパティはプロトタイプ チェーンによって決まります。これは、コードのどの部分についても、関数呼び出しで呼び出される関数を決定する前に、オブジェクトの型を推測し、プロトタイプ チェーンに沿ってチェックする必要があることを意味します。

たとえば、$(x).bind()o$(x).mapが ecmascript5mapまたはbind関数を呼び出しているのではなく、jQuery を呼び出していることを認識できる必要があります。これは、コード全体を解析して型を推測する必要があることを意味します。コードベース全体がなければ、これは不可能です。オブジェクトを受け取る関数があり、bind を呼び出した場合、それが本来あるべきものなのFunction.prototype.bindかjQuery.bind、実行時まで決定されないためなのかわかりません。実際には (適切なコーディング方法ではありませんが) 両方である可能性があり、実行される内容が関数への入力に依存するか、ユーザー入力に依存することさえあります。したがって、これについて推測することはできるかもしれませんが、正確に推測することはできません。

これらすべてをさらに不可能にしているのは、ユーザー入力または ajax データを取得する機能と組み合わせた eval 関数は、一部のオブジェクトがどのタイプであるか、またはどのようなタイプになる可能性があるかさえわからないことを意味します。あらゆる仕様を満たすコード。

解析できなかったコードの例を次に示します。

var userInput = $("#input").val();

var objectThatCouldBeAnything = eval(userInput);

object.map(function(x){
   return !!x; 
});

このコードが eval で jQuery オブジェクトを解析して実行しているjQuery.mapのか、配列を生成して実行しているのかを判断する方法はありませんArray.prototype.map。これが、JavaScript のような動的型付け言語の長所と短所です。これは非常に高い柔軟性を提供しますが、実行前にコードについて言えることは限られています。

なぜそれが良い戦略ではないのか

ECMAScript の仕様は標準ですが、実際には完全に実装されたり、一貫して実装されたりすることはありません。環境が異なれば、標準のさまざまな部分が実装されます。「ECMAScript5」コードを使用しても、特定のブラウザーがそのすべてのプロパティを完全に実装することは保証されません。プロパティごとにそれを決定する必要があります。

コードで使用されている関数またはプロパティのリストを見つけることをお勧めします。その後、特定の環境でサポートされているプロパティと比較できます。

上記の理由から、これは依然として困難から不可能な問題ですが、少なくとも有用な問題です。そして、大まかな近似を使用しても、これを行うことで価値を得ることができます (ラップbindされていない限り、実際には ecmascript5であると仮定し$()ます。これは完璧ではありませんが、それでも役立つ可能性があります)。

実装されている標準を理解しようとすることは、特定の環境でそれを使用するかどうかを決定するのに役立つという点で実用的ではありません. 環境と比較し、必要に応じてポリフィルを追加できるように、使用している関数またはプロパティを把握しておくことをお勧めします。

于 2013-03-24T23:50:32.030 に答える