Erste closure-compiler und Node.js zu spielen schön

Habe ich mit dem Closure Compiler mit Knoten für ein Projekt, das ich noch nicht freigegeben, noch. Es hat ein bisschen von Werkzeugen, aber es hat dazu beigetragen, fangen viele Fehler und hat eine Recht kurze Bearbeiten-neu starten-testen-Zyklus.

Erste, die ich verwenden plovr (was ist ein Projekt, das ich erstellt und halten), um den Closure Compiler, - Bibliothek und-Templates zusammen. Ich Schreibe meine Knoten code im Stil der Schließung der Bibliothek, so dass jede Datei definiert eine eigene Klasse oder eine Sammlung von Dienstprogrammen (wie goog.array).

Der nächste Schritt ist die Erstellung einer Reihe von externs-Dateien für die Node-Funktionen, die Sie verwenden möchten. Ich veröffentlichte einige dieser öffentlich an:

https://github.com/bolinfest/node-google-closure-latitude-experiment/tree/master/externs/node/v0.4.8

Aber letztlich, ich denke, dass dies ein mehr von der Gemeinschaft angetriebene Sache, denn es gibt eine Menge von Funktionen zu dokumentieren. (Es ist auch ärgerlich, weil einige Knoten Funktionen haben optionale mittleren Argumente eher als Letzte Argumente, so dass die Typ-Annotationen kompliziert.) Ich habe noch nicht angefangen diese Bewegung mich, denn es ist möglich, dass wir etwas tun könne mit der Schließung Complier, um diese weniger umständlich (siehe unten).

Sagen, Sie haben die externs-Datei für den Node-namespace http. In meinem system habe ich beschlossen, dass ich immer wenn ich brauche http ich wird es über:

var http = require('http');

Obwohl ich nicht zählen, die require() Anruf in meinem code. Stattdessen verwende ich die output-wrapper Funktion der Closure Compiler das voranstellen alle require()s am Anfang der Datei, die, wenn Sie erklärt, in plovr, in meinem aktuellen Projekt sieht das so aus:

"output-wrapper": [
  //Because the server code depends on goog.net.Cookies, which references the
  //global variable "document" when instantiating goog.net.cookies, we must
  //supply a dummy global object for document.
  "var document = {};\n",

  "var bee = require('beeline');\n",
  "var crypto = require('crypto');\n",
  "var fs = require('fs');\n",
  "var http = require('http');\n",
  "var https = require('https');\n",
  "var mongodb = require('mongodb');\n",
  "var nodePath = require('path');\n",
  "var nodeUrl = require('url');\n",
  "var querystring = require('querystring');\n",
  "var SocketIo = require('socket.io');\n",
  "%output%"
],

In dieser Weise, meine Bibliothek code ruft nie Knotens require(), aber der Compiler toleriert, die verwendet Dinge wie http in meinem code, da der Compiler erkennt Sie als externs. Wie, Sie sind nicht wahr externs, müssen Sie vorangestellt werden, wie ich beschrieben.

Schließlich, nach einem Gespräch über diese auf der Diskussionsliste, ich denke die bessere Lösung ist, um eine neue Art Anmerkung für namespaces, würde folgendermaßen Aussehen:

goog.scope(function() {

    /** @type {~NodeHttpNamesapce} */
    var http = require('http');

    //Use http throughout.

});

In diesem Szenario ein externs Datei definieren NodeHttpNamespace so, dass der Closure Compiler in der Lage sein würde, typecheck Eigenschaften auf, die es mit den externs-Datei. Der Unterschied hier ist, dass man dem Namen den Rückgabewert require() was auch immer Sie wollte, weil der Typ von http wäre diese spezielle namespace-Typ. (Die Bestimmung eines "jQuery-namespace" für $ ist ein ähnliches Problem.) Dieser Ansatz würde die Notwendigkeit beseitigen, den Namen Ihrer lokalen Variablen für Knoten namespaces konsequent, und würde die Notwendigkeit beseitigen, für das riesige output-wrapper im plovr config.

Aber das war ein Exkurs...wenn ich Dinge wie oben beschrieben, habe ich ein shell-Skript, dass:

1. Verwendet plovr zu bauen ist alles in RAW - Modus.
2. Läuft node auf die Datei, die generiert plovr.

Mit RAW - Modus führt zu einer großen Verkettung aller Dateien (obwohl es kümmert sich auch um die übersetzung von Soja-Vorlagen und sogar CoffeeScript zu JavaScript). Zugegeben, das macht das Debuggen von Schmerzen, weil die Zeilennummern sind Unsinn, hat aber funktioniert gut genug für mich so weit. Werden alle Prüfungen durchgeführt, indem der Closure Compiler gemacht haben, es lohnt sich.

InformationsquelleAutor bolinfest

Ersetzte ich meinen alten Ansatz mit einem Weg, einfacher Ansatz:

Neuen Ansatz

• Keine require () - Aufrufe für meine eigene app-code, nur für Node Module
• Ich muss zum verketten von server-code zu einer einzigen Datei, bevor ich laufen kann, oder kompilieren Sie es
• Verketten, und das kompilieren erfolgt mit ein einfacher grunt-Skript

Lustige an der Sache ist, dass ich gar nicht hatte, um eine extern-für die require() Anrufe. Der Google Closure compiler versteht, dass automagisch. Ich habe, um das hinzufügen externs für nodejs-Module, die ich benutze.

Alten Konzept

InformationsquelleAutor Blaise

Option 4: keine closure compiler.

Menschen, die im Knoten Community (Gemeinschaft) nicht dazu neigen, es zu benutzen. Sie brauchen nicht zu minifizieren node.js source code, das ist blöd.

Gibt es einfach keine gute Nutzung für die Verkleinerung.

Als für die performance-Vorteile der Schließung, ich persönlich bezweifle es tatsächlich macht Sie Ihre Programme schneller.

Und natürlich gibt es eine Kosten -, debugging kompiliert JavaScript ist ein Alptraum

InformationsquelleAutor Raynos