Erstellen eines Codemod-Tools zum Umschreiben von Standardexporten

Kürzlich haben wir bei der Arbeit beschlossen, auf die genannten Exporte/Importe zu migrieren und die eslint-Regel no-default-export hinzuzufügen.

Motivation klang ungefähr so:

Die Standardexporte können die Pflege des Codes erschweren, insbesondere in großen Codebasen. Importierte Namen können für dieselbe Entität unterschiedlich sein, was sich auf den Code-Lesevorgang und das Schreiben statischer Analysatoren auswirkt und es schwieriger macht. Umgekehrt werden durch den Wechsel zu benannten Exporten alle Nachteile der Standardexporte beseitigt.

Natürlich haben wir eine riesige Codebasis und es ist keine interessante Aufgabe, ~1500 Standardexporte und ~12000 Standardimporte manuell zu ersetzen?

Die Hauptschwierigkeit bestand darin, alle verknüpften Dateien mit derselben neuen Kennung zu aktualisieren, die für den benannten Export erstellt wurde.

Ich gebe Ihnen ein Beispiel:

// Button/Button.tsx
const Button = () => {};
export default Button;

// Button/index.ts
export { default } from './Button.tsx';

// SomePage1.tsx
import OldButton from './component/Button';

// SomePage2.tsx
import TestButton from './component/Button';

Und das von mir angenommene Zielergebnis würde so aussehen:

// Button/Button.tsx
export const Button = () => {};

// Button/index.ts
export { Button } from './Button.tsx';

// SomePage1.tsx
import { Button as OldButton } from './component/Button';

// SomePage2.tsx
import { Button as TestButton } from './component/Button';

Jede Lösung, die ich im Internet gefunden habe, war nur ein Codemod, um jede Datei unabhängig umzuwandeln, ohne etwas anderes außerhalb dieser Datei zu wissen.

Ich begann von einem Parser zu träumen, der:

1. Alle Importe im Projekt auflösen und Beziehungen zwischen Dateien speichern
2. Informationen zum Standardimport/-export sammeln
3. Erstellen Sie einen neuen Bezeichnernamen für den benannten Export
4. Alle Einträge im gesamten Repo ersetzen?

Also habe ich mich einer neuen Herausforderung gestellt und ein Codemod-Tool entwickelt, das Standardexporte/-importe automatisch in benannte umschreibt.

Entwicklungsprozess

Erste Gedanken
Es geschah direkt nach meinem vorherigen Experiment Visualize React Components Tree und die erste Idee bestand darin, die Babel- und Webpack-Plugins wiederzuverwenden, um alle Module zu durchlaufen und den AST zu analysieren, aber warum, wenn jscodeshift bereits über den Parser verfügt und ich einen Ersatz dafür gefunden habe Mit dem Webpack-Plugin könnte ich ein Bundler-agnostisches Tool schreiben, großartig?

Werkzeuge
Ok, ich habe einen Jscodeshift als Parser. Aber um Beziehungen zwischen allen Dateien ab dem Einstiegspunkt zu finden, habe ich das Auflösungspaket gefunden, das dabei hilft, Pfade wie native Nodejs require.resolve aufzulösen, aber es ähnelt eher dem Auflösen von Pfaden wie Bundlern, Sie haben mehr Kontrolle über Erweiterungen und Synchronisierung /async-Verhalten usw.

Entwicklung des zweistufigen Prozesses
Die ursprüngliche Version meines Tools war wie alles in einem Skript. Um jedoch die Flexibilität und Leistung zu verbessern und auch den Entwicklungsprozess beim Debuggen zu vereinfachen, habe ich das Tool in zwei Phasen umgestaltet:

1. Datenerfassung: In der ersten Phase werden alle Instanzen von Standardimporten und -exporten in der gesamten Codebasis erfasst

   • Ich habe eine Umgebungsvariable, IS_GATHER_INFO, eingeführt, um diese Phase zu steuern. Das Skript verwendet „resolve“, um jede Verwendung eines Standardexports/-imports zu finden
   • Ein weiterer Env-Var-EINTRAG enthält einen relativen Pfad zu Ihrem Codebasis-Einstiegspunkt. Ausgehend von dieser Datei werden alle Importe aufgelöst und analysiert

2. Transformation: Sobald die Daten erfasst sind, werden in der zweiten Phase die Standardexporte in benannte Exporte umgeschrieben. Mit jscodeshift habe ich den Quellcode parallel und einfach transformiert.

   • Ich habe eine Umgebungsvariable, IS_TRANSFORM, eingeführt, um diese Phase zu steuern

Durch die Aufteilung in diese beiden Schritte:

• Ich konnte die Datenerfassung von der Transformation entkoppeln und so die Menge des ausgeführten Codes und den Zeitaufwand für Entwicklung und Debugging reduzieren
  • Es ist eine sehr praktische Möglichkeit, das Ergebnis der Funktion „gatherInfo“ anzuzeigen, es zu analysieren und Ihren Code erneut auszuführen
  • Testen Sie Transformationen, ohne die gesamte Pipeline wiederholt mit den erfassten Daten auszuführen
• Das Sammeln des Datendumps ist hilfreich, wenn Sie dieses Tool für verschiedene Einstiegspunkte ausführen, die gesammelten Daten aber wiederverwenden müssen

Als sich die Fälle zu häufen begannen (z. B. dynamische Importe, erneut exportierte Standardeinstellungen, verschiedene exportierte Entitäten: Variablen, Funktionen und Klassen sowie bereits verwendete Namen von Variablenproblemen), verbrachte ich zusätzliche Zeit damit, Testfälle einzurichten. In etwa 30 Minuten hatte ich einen soliden Testaufbau, der es mir ermöglichte, zur testgetriebenen Entwicklung (TDD) überzugehen. Vertrauen Sie mir, es lohnt sich, Zeit mit TDD für solche Tools zu verbringen, bei denen es eine enorme Anzahl von Fällen gibt. Je weiter Sie gehen, desto wertvoller werden Ihre Testfälle. Ich würde sagen, dass es nach der Abdeckung der Hälfte der Fälle ohne Tests zu einem Albtraum wird, ein riesiges Projekt auszuführen und zu debuggen, da jedes Mal, wenn Sie einige Änderungen hinzufügen müssen, möglicherweise viele andere Fälle zum Scheitern verurteilt sind.

AST:
Ich habe die folgenden Arten von AST-Knoten verwendet:

• ImportDefaultSpecifier, um nur Import-Standardanweisungen zu finden
  • etwas importieren von '...'
• ExportDefaultDeclaration, um nur Export-Standardanweisungen zu finden
  • Standardmäßig etwas exportieren;
• ExportNamedDeclaration zum Suchen von Import-Default- und Export-Default-Anweisungen
  • export { etwas als Standard } aus '...' - Standardexport
  • export { default as Something } from '...' - Standardimport
  • export { default } from '...' – Standardimport und Standardexport gleichzeitig
• ImportExpression, um den dynamischen Import zu finden und diese Datei als erforderlich zu markieren, um den Standardexport beizubehalten. Einige Tools wie React.lazy funktionieren nur mit dem Standardexport.
  • import('...')
• Außerdem habe ich Informationen über Proxy-Dateien gespeichert, das sind Dateien, die etwas als Standard importieren und dieses als Standard exportieren
  • Wird damit verwendet, um den neuen Namen des benannten Exports in einer beliebigen Datei zu finden: Datei a -> Datei b -> Datei c

Technische Überlegungen und bekannte Einschränkungen
Obwohl das Tool funktionsfähig ist, gibt es einige Randfälle, die es noch nicht behandelt:

namespace.default-Verwendung
Der folgende Code wird noch nicht transformiert:

// Button/Button.tsx
const Button = () => {};
export default Button;

// Button/index.ts
export { default } from './Button.tsx';

// SomePage1.tsx
import OldButton from './component/Button';

// SomePage2.tsx
import TestButton from './component/Button';

Konflikte in Proxy-Dateien
Quelle:

// Button/Button.tsx
export const Button = () => {};

// Button/index.ts
export { Button } from './Button.tsx';

// SomePage1.tsx
import { Button as OldButton } from './component/Button';

// SomePage2.tsx
import { Button as TestButton } from './component/Button';

Ergebnis:

import * as allConst from './const';
console.log(allConst.default);

Fehlerhafte Exporte wie
Quelle:

export { Modals as default } from './Modals';
export { Modals } from './Modals';

führt zu einer fehlerhaften Logik, da es jetzt zwei gleiche Exporte mit unterschiedlicher Implementierung gibt:

export { Modals } from './Modals';
export { Modals } from './Modals';

Und Importe für die vorherige Entität sollten auch manuell korrigiert werden
Quelle:

export class GhostDataProvider {}
export default hoc()(GhostDataProvider);

Ergebnis:

export class GhostDataProvider {}
const GhostDataProviderAlias = hoc()(GhostDataProvider);
export { GhostDataProviderAlias as GhostDataProvider };

Trotz dieser Einschränkungen habe ich den Rest der Fehler in 15–20 Minuten manuell behoben und unser eigentliches Projekt erfolgreich gestartet. Die rewrite-default-exports.

Links

• jscodeshift
• astexplorer

Das war's, willkommen zu den Kommentaren unten! ?

Das obige ist der detaillierte Inhalt vonErstellen eines Codemod-Tools zum Umschreiben von Standardexporten. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!