ES2015でプレーン文字列を使い続ける理由はありますか？
私の現在のコーディングスタイルは、デフォルトとして一重引用符で囲まれた文字列を使用し、値を文字列に連結する必要がある場合は常にバッククォートされたテンプレートリテラルを使用することです。
しかし、今、2種類の文字列を使用することの意味は何なのでしょうか。おそらく、すべてをシンプルにするために、テンプレートリテラルに固執する方が良いでしょう。動的な値を実際にテンプレートリテラルに補間していない場合でも、テンプレートを使用すると、リテラルの引用符（リテラルのバックティックよりもはるかに頻繁に発生します）をエスケープする必要がないという他の利点があります。
そのため、プレーンクォートされた文字列（シングルまたはダブル）を使用したときに警告するようにリンターを構成することを検討しています。美学はさておき、これが問題を引き起こす理由はありますか？
チームが backticked strings を頻繁に使用してその利点（テンプレート拡張、複数行文字列、異なるエスケープ、タグ付きテンプレート）を使用している場合、その1つの構文を使用することで、間違いを減らすことができます。これは、（1）エスケープルールに慣れ、（2）${ }テンプレートプレースホルダーを追加するときに引用符とエスケープを変更する必要がない（覚えておく）必要がないためです。（3）文字列リテラルを変換する価値があるかどうかを判断するための余談。また、タグ付きテンプレートについて覚えているので、誤ってタグ付き文字列を書き込む可能性が低くなります。バックティックストリングを使用するリズムになり、他のすべてのことから気が散ることが少なくなります。
一方、チームが'および"文字列リテラルをほとんど/排他的に使用するライブラリコードまたはクライアント側コードに頻繁に触れる場合は、どのソースファイルがそれを必要とするかを認識し続ける必要があります。構文。さらに、バックティック文字列の新機能をほとんど使用しない場合は、必要な場合にのみバックティック文字列を書き込むことでミスを減らすことができます（ただし、プレースホルダーを削除した後で文字列を元に戻すことはお勧めしません）。
もう1つの要素は、エディター/ IDEでのバッククォート文字列のサポートレベルです。構文の色付けにより、${expression}プレースホルダーとテンプレートタグが明らかになり、間違いが目立ちやすくなる場合があります。リファクタリングコマンドは、フォーマット間ですばやく変換し、後でプレースホルダーを追加する場合に備えて、バッククォートされた文字列を使用するインセンティブを1つ削除する場合があります。 OTOHバッククォートされた文字列がエディター/ IDEを混乱させる場合は、それを修正するまで控えめに使用することをお勧めします。
[プログラミングプロセスを十分に考慮した場合、これらのような仮説をテストします。つまり、代替案を測定します。]