2017-06-29 1 views
6

Angesichts der folgenden Typoskript Datei,auslassen "require" und "Exporte" von Typoskript emittierten AMD Abhängigkeiten

export = {}; 

tsc (mit "module": "amd") emittieren:

define(["require", "exports"], function (require, exports) { 
    "use strict"; 
    return {}; 
}); 

Allerdings würde ich es eher emittieren

define([], function() { 
    "use strict"; 
    return {}; 
}); 

... und nur schließen require oder exports wenn ich sie explizit importieren, das heißt

import relativeRequire = require("require"); 

Gibt es eine Möglichkeit Typoskript zu sagen, nicht require und exports in emittierten AMD-Module zu emittieren (d frage es nicht den zu verwenden)?

Hinweise:

  • Der Ausgang Ich schlage vor, mit dem AMD spec vollständig kompatibel ist.
  • Eine leere Abhängigkeiten Array ist das only way für das Modul Null Abhängigkeiten haben (wie zum Weglassen der Abhängigkeiten Array gegenüber, die die require impliziert, exports und module Abhängigkeiten).

UPDATE 4. Juli 2017: Sieht aus wie das ist eigentlich eine offene Frage im Typoskript GitHub Repo ist: https://github.com/Microsoft/TypeScript/issues/669

Irgendwelche Ideen für eine pragmatische Problemumgehung, bis dies umgesetzt wird? (Oder gibt es tatsächlich eine Möglichkeit, TypeScript das zu ermöglichen?)

Antwort

3

Ich sehe keinen wesentlichen Vorteil in dem, was Sie versuchen zu tun. Welche Ausführungszeit auch immer gespeichert wird, indem die nicht verwendeten Abhängigkeiten entfernt werden, wird gegenüber der Ausführungszeit des Rests der App für jede App, die mehr als eine Spielzeug-App ist, in den Schatten gestellt. Sowohl als auch exports sind virtuelle Module, deren Instanziierung sehr wenig kostet. (Mit "virtuell" meine ich, dass sie für den von Ihnen verwendeten AMD-Loader völlig intern sind und kein Laden aus dem Netzwerk oder einer Datei auf der Festplatte erfordern.) Ich sehe issue 669, die Sie seit September 2014 erwähnt haben und seither als "akzeptiert" gelten April 2015. Niemand scheint so sehr zu schmerzen, dass sie sich beeilen, um eine Pull-Anfrage zu stellen.

Ich weiß in keiner Weise ArtScript wird tun, was Sie aus der Box wollen. Ich habe kürzlich untersucht, wie TypeScript seine Aufrufe ausgibt, weil ich das virtuelle Modul mit dem Namen "module" zu der Liste der Abhängigkeiten hinzufügen musste. (Wenn Sie Angular verwenden, möchten Sie module.id verwenden, um die ID des aktuellen Moduls an Angular zu übergeben, damit z. B. relative Vorlagenpfade aufgelöst werden können. Sie können module.id ohne Problem mit CommonJS-Ausgabe verwenden, aber mit AMD-Ausgabe module nicht Standardmäßig bin ich in der Liste der Abhängigkeiten enthalten.) Ich habe das Problem behoben, indem ich einen Build-Schritt geschrieben habe, der den von tsc ausgegebenen Code ändert, nachdem tsc ihn ausgegeben hat. Es verwendet eine Regexp, die die Abhängigkeitsliste ändert, um "module" hinzuzufügen, und ändert den Rückruf, um das entsprechende Argument hinzuzufügen. Das funktioniert für mich, weil ich hinzufüge.Es ist kein guter Ansatz für das, was Sie zu tun versuchen, weil Sie Abhängigkeiten entfernen möchten. Es kann jedoch Fälle geben, in denen das Entfernen von Code zu ungültigem Code führt.

Für eine Abhilfe Sie Esprima verwenden könnte das JavaScript erzeugt durch tsc und wenn die Werte der Module "require" und "exports" zu untersuchen, werden nicht durch den Code innerhalb der Fabrik Funktion define geben verwendet, entfernen Sie dann die nicht benötigten Module aus der Abhängigkeitsliste und den entsprechenden Argumenten aus der Argumentliste, die an die Factory-Funktion übergeben wurde. Dies wäre die allgemeinste Lösung. (Unter anderem wäre es kompatibel mit dem asynchronen Aufruf require, den AMD-Loader innerhalb der Factory-Funktion zur Verfügung stellen (in der Form require([...], function (...) {})).) Aber das Codieren dieser Logik mag genauso involviert sein wie das Erzeugen einer Pull-Anfrage have tsc streamen Sie den Code, den Sie in erster Linie wollen.

+0

Ich arbeite mit einer ziemlich großen App mit mehreren tausend AMD-Modulen, von denen etwa 1300 beim App-Start geladen werden - und somit Teil der ursprünglich gelieferten Assets sein müssen. Ich habe bereits die meisten Leistungsgewinne der niedrig-hängenden Ladezeit erreicht und die Reduzierung der Asset-Größe (und vielleicht die Beseitigung unnötiger virtueller Module) ist nur ein weiterer Teil des langen Tail der kleinen Verbesserungen, die gemacht werden können. –

1

Erfordern

Sie sagte:

.. und sind nur oder Exporte verlangen, wenn ich sie explizit importieren, dh import relativeRequire = require("require");

Sie nicht require es sei denn, seine bereits dort verwenden können . Also ist es gut, dass es da ist.

Exporte

exports wird, sobald Sie etwas exportieren benötigt. Wenn Sie einen Root-Export wie in export = haben möchten, stellt TypeScript ihn auf return. Aber mit export const foo = 123 müsste exports verwendet werden.

Es kann nicht schaden, dass es da ist und die Auswirkungen auf die Leistung sind wirklich minimal.

+0

Dieses Projekt verwendet niemals 'exports' und nur gelegentlich' require'. Module werden mit 'return ThisClass;' exportiert. (Es verwendet den Dojo-Modullader, wenn dies irgendeinen klarstellt.) –

Verwandte Themen