再構築前のES 6の古いコードを自動化する方法

今日、JavaScriptの言語標準の反復は非常に迅速で、これは良いことですが、多くのフロントエンドの古いプロジェクトでコードの腐敗を加速させました.歴史のある古いプロジェクトを引き継いだことがあると信じている学生は、これに多少感銘を受けた.では、古いコードを新しい基準に自動的に移行できますか?答えは肯定的だ.
次の手順では、古いコードを再構築するためのいくつかの自動化の方法について説明します.

地味処理

ESLint

正規マッチング

Codemod

地味に扱う

履歴コードの最も基本的な処理方法と素朴な処理方法については、大きく2つにまとめることができます.

履歴コードのルートに従って穴を埋め続けます.

どこの需要を書くか、そこのコードを新しいものに変更します.

この2つの方法はもちろん可能ですが、古いコードに完全に基づいて穴を埋め続けると、メンテナンス性は規範の発展に伴って徐々に低下します.変更されると、多くの場合、このような問題に直面します.

コード・ウェアハウス全体で新しい構文を使用する場所もあれば、古い構文を使用する場所もあります.このような不一致は困惑をもたらします.

コミット履歴では、古いコードの変更と本当の機能的な変更が混在し、コードreviewのコストが増加します.

したがって,中大規模なプロジェクトでは,新しい特性を開発しながらコードスタイルを修正する実践が最適とは言い難い.コードライブラリを更新するには、より一括的で自動化された方法が必要です.既存のESLintから始めましょう.

ESLint

新しい先端工事に対して、ESLintはほとんど基本的な品質保証標準です.したがって、ここでは、このツールのインストール、使用方法を説明するのではなく、古いプロジェクトのコードスタイルのアップグレードにおける役割を簡単に共有します.
古いプロジェクトにESLintがインストールされている限り、npxコマンドを簡単に使用できます.これにより、スタイルが統一されていない古いコードを一貫したスタイルに自動化することができます.

npx eslint --fix

これは複雑な操作ではありませんが、ESLintのコードスタイルに対する制約は、後の変更でコードライブラリの安定性を維持するのに役立ちます.したがって,以下に述べるような一括変更を行う場合には,ESLintをベースとした支援が非常に推奨される.

正規一致

ESLintに詳しい人は、一般的なpresetルールではES 5やES 6スタイルの使用を制限しないことを知っているはずです.したがって、コードライブラリをES 5からES 6に移行する場合、既存のeslint --fixは直接的に役に立つのではなく、他の手段が必要である.ここではまず正則マッチングから始めましょう.
最も簡単な正則マッチングは、実際には文字列が置き換えられています.文字列の置換を軽視しないでください.場合によっては最も簡単に使用できます.例えば、VueでES 5からES 6に移行する場合、以下のような一般的な書き方が移行可能である.

// old
methods: {
  foo: function () { /* ... */ }
}

// new
methods: {
  foo() { /* ....*/ }
}

このとき、VSCodeのようなエディタで: function (を(にフルに置き換えることで、コードスタイルを自動的にアップグレードすることができます.しかし、少し複雑なルールでは、単純な文字列マッチングは明らかに不十分です.このとき,一括処理コードファイルのノードスクリプトを記述して実装最適化を変更することができる.たとえば、lodashのオンデマンド・ロードを実現するための最適化を最近実現しました.

// old
import lodash from 'lodash'
lodash.merge(/* ... */)

// new
import { merge } from 'lodash'
merge(/* ... */)

このような更新は、構文ツリーのimportと関数呼び出し文の構文を変更する必要があり、自動化が難しい最適化のようです.しかし、実際には、一致する必要がある関数呼び出しがlodash.xxxの形式を満たしていることに気づく限り、このようなアルゴリズムを正則に基づいて実現することは難しくありません.

は、コード内のすべてのlodash.xxx宣言を一致させるために使用される.

は、一致するmerge/cloneなどのメソッド名を用いて、import文を置換する.

既存のlodash.xxxを置き換えます.

これにより、自動化されたコードスタイルのアップグレードを実現できます.例として、上記の手順を実装したNodeスクリプトは実際には長くありません.

const glob = require('glob')
const fs = require('fs-extra')

const filePath = process.argv[2]

// Usage
// node index.js ../foo/\*.js
glob(filePath, (err, files) => {
  if (err) throw err

  files.forEach(file => {
    fs.readFile(file, 'utf8').then(code => {
      const re = /lodash\.(.)+?\(/g
      const matchResults = code.match(re)

      if (!matchResults) return
      console.log('mod', file)

      const methodNames = matchResults.map(
        result => result.replace('lodash.', '').replace('(', '')
      )
      const filteredNames = Array.from(new Set(methodNames))
      let modCode = code.replace(
        `import lodash from 'lodash'`,
        `import { ${filteredNames.join(', ')} } from 'lodash'`
      )
      matchResults.forEach((result, i) => {
        // eslint-disable-next-line
        const re = result.replace('.', '\\.').replace('(', '\\(')
        modCode = modCode.replace(new RegExp(re, 'g'), methodNames[i] + '(')
      })
      fs.writeFile(file, modCode, 'utf8')
    })
  })
})

1行の肝心な/lodash\.(.)+?\(/gの正則だけで、私たちはよく知っているツールを利用してコードスタイルを一括的に変更することができます.大きく聞こえますか?このようなあまり重要ではないコードスタイルで振り回されるのは実際の効果があるのではないかと疑問に思うかもしれません.パフォーマンスの最適化では、上記のスクリプトは、エディタコードウェアハウスに適用された後、lodashに対する200以上の呼び出し文を自動的に再構築します.再構成後、babel-plugin-importのモジュールローディング文に合わせて最適化され、lodashが非圧縮コードに占める体積は526 Kから162 Kに減少した(対照的に、Vue runtimeの非圧縮体積は204 K).これは私たちが圧縮していない体積の1/4にほぼ相当します.つまり、ビジネスロジックを複雑に再構築する必要がなく、パッケージのサイズを25%削減できます.この効果はやはり私たちを満足させた.
もちろん,純粋な正則に基づく再構成は明らかにコード構造を破壊するリスクがある.たとえば、役割ドメインがmerge関数を宣言した場合、lodash.mergeをmergeに置き換える操作に問題があります.幸いなことに、ESLintを構成すれば、この動作はESLintによってタイムリーに発見され、修正され、繰り返しの煙テストを必要とせずにコード動作の一貫性を保証することができます.これも前述のLint優先を強調した理由です.

Codemod

実際,ES 5からES 6に至るまで,多くの文法的スタイル遷移が正規表現の表現力でカバーできるものではないことは明らかである.例えば、varからletとconstのアップグレードは、変数が存在する役割ドメインにRe-assignの動作があるかどうかを考慮する必要がある.たとえば、functionをより簡潔な矢印関数に一括して移行するには、関数内に破壊される可能性のあるthis参照があるかどうかを考慮する必要があります.これらのタイプのコードスタイルのアップグレードについては、より正確なツールとしてCodemodを導入することができます.
現在、JSコミュニティのjscodeshiftツールは、上記のスタイルの移行を自動化するのに役立ちます.このツールは、開発したCodemodスクリプトに基づいて、移行コードスタイルを自動化することができます.この方法で使用できます.

グローバルインストールjscodeshift

変更が必要なコードウェアハウス外部clone js-codemodウェアハウス

Codemod

を実行する.
ツールのインストールが完了したら、varをletとconstに自動化して置き換える移行を使用するには、次のようにします.

jscodeshift -t js-codemod/transforms/no-vars.js your-old-repo

コミュニティには既存のCodemodスクリプトも多数用意されており、オンデマンドで入手できます:-)

小結

自動化された改造コードスタイルは、プロジェクトコードをより一貫して整備するほか、追加のパフォーマンス向上を実現します.上記では、このような改造を実施する方法をいくつか紹介したが、複雑で表現力のある手段ほど、より多くの開発とデバッグコストを意味することが多いため、実際の工事実践では、実際の需要分析に基づいて、既成のツールや最小の代価で実際の、量子化可能な工事問題を解決することをより推奨している.スペース、インデント、改行にこだわるのではなく、ツールで自動化してあげましょう.