Less.js: ES6 & Rollup

NÖ. Ich denke schon seit einiger Zeit in die gleiche Richtung. Was ist mit der Verwendung von TypeScript? Es könnte die Entwicklung / Beiträge einfacher machen, Code-Hinweise / echte Objektverknüpfungen zu haben. Obwohl ich nicht weiß, ob dies dann eine Wissenslast / -barriere darstellen würde.

Ich dachte auch in die gleiche Richtung, dass wir erwägen sollten, es6-Sammlungen für das Parsing / AST zu verwenden und dann ein Polyfill für es5-Builds wie https://github.com/Benvie/harmony-collections zu verwenden. In es6-Umgebungen (was Node.js jetzt ist, ebenso wie die neuesten Browser) sollte das Parsing/Evaluierung theoretisch beschleunigen, da der Speicheraufwand reduziert und die AST-Konstruktion schneller ist.

Was ist mit der Verwendung von TypeScript? Es könnte die Entwicklung / Beiträge einfacher machen, Code-Hinweise / echte Objektverknüpfungen zu haben. Obwohl ich nicht weiß, ob dies dann eine Wissenslast / -barriere darstellen würde.

Wir können bedenken, dass nach ES6 - es6 Typoskript nicht ausschließt, da Typoskript auch ein es6-Transpiler ist. Es wäre danach ein zusätzlicher Schritt.

Ich persönlich würde Typoskript nicht empfehlen, es sei denn, es würde erhebliche zusätzliche Arbeit oder Refactoring in weniger geben. IMO Typoskript

• + erleichtert die Entwicklung für neue Leute, die sich mit Typoskript auskennen
• + erhöht die Wartbarkeit
• 
  
  • erfordert, dass die Leute eine minimale Menge an Typoskript kennen oder lernen
  
  
• 
  
  • dauert länger, Code zu schreiben, damit er getippt wird
  
  

Ich dachte auch in die gleiche Richtung, dass wir erwägen sollten, es6-Sammlungen für das Parsing / AST zu verwenden und dann ein Polyfill für es5-Builds wie https://github.com/Benvie/harmony-collections zu verwenden. In es6-Umgebungen (was Node.js jetzt ist, ebenso wie die neuesten Browser) sollte das Parsing/Evaluierung theoretisch beschleunigen, da der Speicheraufwand reduziert und die AST-Konstruktion schneller ist.

Ich würde diese Polyfill nicht verwenden, das Projekt sieht tot aus (vielleicht auch, weil der Name Harmony tot ist).

Außerdem wäre ich mir leider nicht sicher, ob die nativen ES6-Äquivalente schneller sind - https://jsperf.com/property-access-object-array-map-weakmap/6. Es ist traurig, wie zum Beispiel das Promise-Polyfill schneller ist als die native Implementierung :(

:+1:

Alles gute Punkte. Die Standardisierung auf ES6 / Babel erleichtert oft nicht nur das Schreiben, sondern auch das Lesen, insbesondere bei der prototypischen Vererbung.

Was diesen jsperf-Test angeht, ist er nicht wirklich ein faires Beispiel. Ich würde erwarten, dass Weakmap für diesen speziellen Test langsamer abschneidet. Theoretisch könnte es für Less besser sein, eine Reihe verschiedener Objektformen und -typen zu erstellen und diese dann zu bewerten. Nicht sicher. Ich habe ein paar gute Bibliotheken gefunden, die ich irgendwann testen (und hoffentlich hinzufügen) möchte, in denen wir uns in einzelne Funktionen einklinken können, um ein granulares Benchmarking durchzuführen, ohne irgendwelche "Benchmarking-Hooks" in die Bibliothek einfügen zu müssen. Ich hoffe, etwas einzurichten (wenn ich Zeit habe, wer weiß, wann das sein wird), damit Sie eine Art jsperf-Test auf Funktionen innerhalb von Less.js durchführen können, aber mit lokalen Entwicklungs- / Zweigänderungen an Less vs aktuelle Version und die Verwendung einiger Arten von .less-Testdateien. Wie ich bereits erwähnt habe, sollten wir nicht raten müssen, was für unseren speziellen Anwendungsfall schneller ist. Wir könnten theoretisch eine WeakMap auf einer bestimmten Funktionsebene im Vergleich zu Rohobjekten einfügen, Benchmarks an dieser Stelle ausführen und basierend auf dem Ergebnis entscheiden.

@lukepage schrieb:
IMO Typoskript

• + erleichtert die Entwicklung für neue Leute, die sich mit Typoskript auskennen
• + erhöht die Wartbarkeit
• 
  
  • erfordert, dass die Leute eine minimale Menge an Typoskript kennen oder lernen
  
  
• 
  
  • dauert länger, Code zu schreiben, damit er getippt wird
  
  

Und einen nicht erwähnten, sehr bedeutenden Vorteil, den Sie überspringen:
Der typisierte Modus von TypeScript zwingt Sie dazu, stabile Variablentypen zu verwenden, was stabile Typformen erzwingt, was die Fähigkeit des Compilers verbessert, Ihren Code sowohl statisch _als auch_ dynamisch zu analysieren, was _viel besseren_ optimierten Code erzeugt und Backouts stoppt (oder zumindest drastisch reduziert). optimierten Code zurück zu langsam interpretiertem Code.

Der Wechsel zu TypeScript würde wahrscheinlich mehr beitragen als der Wechsel zu ES6, imho.

Mit getipptem Modus meinst du das Verbot von Any?

Ich habe das bei einem kleinen Projekt ausprobiert und hatte überall Anmerkungen ... es endet
mit einer Menge Code, weil der Transpiler nicht super schlau ist.

Wie viele Variablen mutierte Variablentypen haben, bin ich mir nicht sicher. Also..
nicht überzeugt, dass der Leistungsvorteil spürbar wäre.

@rjgotten Ich habe TypeScript nicht verwendet, aber das sind gute Punkte. Wenn Sie eine Intellisense-/Autocomplete-Umgebung für TypeScript verwenden, könnte dies neuen Mitwirkenden tatsächlich helfen, da sie Typen/Objektformen vervollständigen würde, wenn Sie Änderungen vornehmen. Richtig gestaltet, könnte es als eine Art selbstdokumentierendes / vertraut machendes / fehlervermeidendes Werkzeug für jemanden dienen, der Codeänderungen beisteuert. Aber der Schlüssel dazu liegt wahrscheinlich im TypeScript-Design.

Würde es insgesamt einen Leistungsvorteil geben? Das ist schwerer zu bestimmen. Das ist mehr der Künstler als die Leinwand.

Auch wenn ich beabsichtige, TypeScript für meine eigenen Projekte zu verwenden, bin ich wahrscheinlich eher geneigt, @lukeapage zuzustimmen , vor allem, weil ich nicht sicher bin, ob wir es effektiv nutzen können, es sei denn, einer von uns hier ist TypeScript-Experte davon zunächst.

Auch die Umstellung auf ES6 verhindert nicht die zukünftige Verwendung von TypeScript. Das Ziel von Microsoft / Google ist es, TypeScript 2.0 zu einem ES6-Superset zu machen, sodass wir immer mit ES6 / Babel beginnen und später die richtigen Typen hinzufügen und zum TypeScript-Transpiler wechseln können. Mein Verdacht ist, dass TypeScript die transpilierten Sprachen "gewinnen" wird, nur weil die Vorteile der Kompilierzeit / der automatischen Vervollständigung so viel größer sind als bei nicht typisiertem JavaScript. Also ... ich denke, das bedeutet, dass ich denke, dass die Verwendung von TypeScript wahrscheinlich unvermeidlich ist, aber das bedeutet nicht, dass wir es sofort verwenden müssen.

Ich würde gerne irgendwann einen anderen architektonischen Ansatz als Less diskutieren, aber das ist eher eine Randdiskussion dazu.

Mit getipptem Modus meinst du das Verbot von Any?

Nein. Nur die Verwendung von typisierten Variablen im Allgemeinen. Sie _können_ generell die Verwendung von Any verbieten, aber es ist (zumindest praktisch) eine schlechte Idee, weil es dazu neigt, zu viel Code-Bloat zu führen, nur um das Tippsystem zu befriedigen.

Die Verwendung von typisierten Parametern für eine Funktion bedeutet jedoch, dass Aufrufer (zumindest in TypeScript geschriebene Aufrufer) den angegebenen Typ respektieren _müssen_. Das heißt, typisierte Funktionen können verwendet werden, um die Typstabilität im Inneren des Less-Compilers zu schützen, wo dies angemessen ist, und garantieren, dass besonders wichtige Funktionen gut optimiert werden. (Vergessen Sie nicht; JS-Engines optimieren im Allgemeinen auf Funktionsebene ...)

Arbeit hat begonnen - https://github.com/less/less.js/tree/rollup

Ziemlich coole Arbeit. Germaine zur Diskussion, ich habe mir den Code angesehen und bin schnell darauf gestoßen:

if (typeof index === 'number') {   

AFAIK, diese Art von Plausibilitätsprüfung wäre in TypeScript niemals erforderlich. Wenn der Indextyp jedes Mal zur Laufzeit in String konvertiert wird, um einen Stringvergleich durchzuführen, um den Typ des Werts zu überprüfen, können sich solche Dinge summieren. Wenn in TypeScript eine Funktion aufgerufen wurde, die einen Index übergab, dieser Typ aber manchmal keine Zahl war und der Index nur eine Zahl _akzeptierte_, dann schlug die Funktion zur Kompilierzeit wegen nicht übereinstimmender Typen fehl, anstatt sie zu benötigen zur Laufzeit getestet werden, wenn solche Prüfungen teurer sind.

Andererseits könnte es sein, dass dies ein isoliertes und seltenes Beispiel ist; Es ist nur etwas, auf das ich gestoßen bin, das relevant zu sein schien.

Ich denke, dass der größte Vorteil von expliziten Typen darin besteht, dass sie leistungsfähigere Tools ermöglichen. Alle (und nur) Orte zu finden, die eine Funktion aufrufen oder überschreiben, ist nur eine Tastenkombination entfernt. Herauszufinden, welche Funktionen die verfügbaren Objekte haben, ist null Arbeit und Refactoring ist sicherer, da der Compiler mehr Fehler generiert. Es macht es auch einfacher, eine neue Codebasis zu lernen - ein Gesamtbild zu bekommen, herauszufinden, welcher Teil des Codes davon abhängt oder dem Codefluss zu folgen, ohne ihn auszuführen, ist in Javascript schwieriger als in Java (zum Beispiel), weil getippte Editoren leistungsfähiger sind.

Ich habe TypeScript noch nicht verwendet, daher weiß ich nicht, ob die Tools ausgereift genug sind, um sich zu lohnen. Vorteil von Javascript ist, dass es jeder kennt, TypeScript ist weniger bekannt.

Insgesamt denke ich, dass der Wechsel zu TypeScript sinnvoll wäre, wenn wir eine Art größeres Refactoring oder riesige neue Funktionen planen, aber es könnte zu viel Arbeit sein, während wir nur kleine Fehler beheben.

Ich denke, dass der Wechsel zu TypeScript sinnvoll wäre, wenn wir eine Art größeres Refactoring oder riesige neue Funktionen planen, aber es könnte zu viel Arbeit sein, während wir nur kleine Fehler beheben.

Dies kann der Fall sein, und um ganz pragmatisch zu sein, @lukeapage hat die Arbeit bereits übernommen, also neige ich dazu zu sagen, dass er zu diesem Zeitpunkt die letzte Entscheidung treffen sollte. :-)

Hey, dazu: Gibt es etwas, was wir tun sollten, um die Leute wissen zu lassen, dass sich die Codebasis ändert? Ich gehe davon aus, dass Sie sonst Zusammenführungskonflikte haben werden.

Nein, es sollten nicht zu viele Konflikte sein. erster Schritt ist nur es6-Module - nicht
Wenn Sie Dateien verschieben, können wir Babel oder Typoskript transparent hinzufügen.

Hallo Leute, wie geht's jetzt?

Daran kann ich arbeiten. @matthew-dean Würden Sie einen Pull-Request akzeptieren?

@alexlur Auf jeden Fall! Meine einzige Sorge ist das Refactoring für den 3.x -Zweig und keine Merge-Konflikte. Es ist also besser, von dort aus zu forken/zu verzweigen. Seit diese Ausgabe geschrieben wurde, gibt es außerdem eine etablierte Konvention zur Verwendung von src/ und dist/ . lib/ wird jedoch manchmal als src/ verwendet, sodass eine Umbenennung wahrscheinlich nicht erforderlich ist.

Es würde auch ein kleines bisschen Neuschreiben des Gruntfiles geben, so dass Tests Builds verwenden und nicht lib/ . (Was der Browsertest macht, ist ein Build in test/ und nicht in dist/ . Der Ordner dist/ ist eine spezielle Grunt-Aufgabe für neue Releases. Beim Testen sollte er dazu bauen test/ ) Danach sollten Sie gut sein, solange die Tests bestehen.

@matthew-dean Hallo. Ich bin mit dem Refactoring fertig, aber ich weiß nicht, wie ich Gruntfile konfigurieren soll, um Tests mit den neu erstellten Dateien auszuführen.

Vielleicht kann ich Ihre Änderungen in einem separaten Zweig zusammenführen und mich um die Integration von Tests kümmern. Ich habe mir nur schnell deine Änderungen angesehen. Korrigieren Sie mich, wenn ich falsch liege, aber ist at-rule fälschlicherweise der Knoten assignment ? Oder hat Github nur vermasselt, wie es das zeigte?

Guter Fang, ich habe die falsche Datei verwendet.

Gibt es eine Mindestversion von Browser/Node.js, die less.js unterstützen muss? Node.js hat ziemlich gute Unterstützung für Promise (seit 0.12), während die Verwendung im Browser im Allgemeinen für Entwickler gedacht ist, die sowieso bereits die neuesten Browserversionen ausführen.

Bearbeiten:

Less.js unterstützt alle modernen Browser (aktuelle Versionen von Chrome, Firefox, Safari, IE11+ und Edge)

Nur Internet Explorer 11 hat Promise nicht eingebaut.

@alexlur
Für die In-Browser-Version von Less würde ich vorschlagen, eine Eigenschaft less.Promise zu erstellen und sie standardmäßig auf window.Promise zu setzen. Und dann lassen Sie Less die Promise-Klasse über less.Promise verbrauchen.

Auf diese Weise funktioniert sowohl für Benutzer moderner Browser als auch für Benutzer, die Promise global polyfill haben, bevor Less geladen wird, alles auf magische Weise. Und Benutzer, die das nicht möchten – oder aus welchen Gründen auch immer nicht dürfen – können mit einem winzigen zusätzlichen Schritt die Dinge zum Laufen bringen. Sie müssen ihre gewählte Promise-Implementierung nur manuell less.Promise zuweisen, bevor sie Less tatsächlich verwenden.

@rjgotten @alexlur Less.js hat bereits Promise Polyfills eingerichtet. Da sind keine weiteren Arbeiten notwendig. Der größte Teil des Codes verwendet dieses Muster:

https://github.com/less/less.js/blob/55380d49e96a6ed561cac4d13a774830aa3c17a3/lib/less/import-manager.js#L5

Auf der Node-Seite ist dieses Problem noch offen: https://github.com/less/less.js/issues/3121

Ohne Feedback und mit einer ziemlich moderaten Anzahl von Mitwirkenden neige ich jedoch dazu, einfach zu sagen, dass Node 4+ vorerst der richtige Weg ist. Wir sollten Dokumente / Tests aktualisieren, um dies widerzuspiegeln.

@matthew-dean Es sollte bereit sein, zu einem separaten Zweig zusammengeführt zu werden .

@alexlur Danke! Ich werde versuchen, bald nachzuschauen. Wird wahrscheinlich nächste Woche sein (es sei denn, jemand anderes hat die Zeit, es zu überprüfen).

Dieses Problem wurde automatisch als veraltet markiert, da es in letzter Zeit keine Aktivität gab. Es wird geschlossen, wenn keine weiteren Aktivitäten stattfinden. Vielen Dank für Ihre Beiträge.

Ich habe einen Fork erstellt, der auf TypeScript umgestaltet wurde.

Ich habe einen Fork erstellt, der auf TypeScript umgestaltet wurde.

@glixlur 😮 Wow, und alle Tests bestanden? Und baut eine identische less.js in dist/ ?

@matthew-dean Ich arbeite noch daran, aber mein Build für den Browser ist bisher als täglicher Treiber auf kein Problem gestoßen. Die technische Verwendung von Rollup gibt meiner Gabel einen Leistungsvorsprung, aber ich habe keine Daten, um dies zu belegen.

@less/core Dies sollte untersucht werden, um zu sehen, ob wir dies für eine einmalige Konvertierung automatisieren können – https://github.com/lebab/lebab

@matthew-dean Ich schicke dir eine Pull-Anfrage, sobald ich fertig bin.

@glixlur Oh! Okay, in deiner vorherigen PR hast du gesagt, du hättest keine Zeit dafür. Falls du noch daran arbeitest, 👍

@matthew-dean Ich beschränke mich darauf, nur in ES6 zu konvertieren und den TypeScript-Teil später zu verlassen.

@glixlur Ich denke, ES6 ist wahrscheinlich der "Community-freundlichste" erste Schritt nach vorne, also ist das perfekt. Ich bin mir nicht sicher, ob alle mit TypeScript an Bord sind, aber ein ES6-Flow wäre definitiv großartig.

@matthew-dean Ich nehme an, die niedrigsten unterstützten Plattformen sind Node 6 und IE11?

@glixlur Appveyor ist derzeit zum Testen von Node 4 eingerichtet. Würde das die Sache schwieriger machen? Im Idealfall wäre es eine Babel-Transformation eines src/ -Ordners in (ersetzte) lib/ -Ordner (und dist/ für Browser) zur Verteilung für Node/Browser. Ich würde also davon ausgehen, dass Babel die meiste Arbeit beim Transpilieren auf ES5 erledigt.

Erledigt , aber die Tests müssen noch funktionieren. PhantomJS ist veraltet und bietet nach ES5 keine Unterstützung mehr.

@glixlur Schön! Betreff: PhantomJS, es muss wirklich durch etwas wie Chromy ersetzt werden. Siehe: https://github.com/less/less.js/issues/3240

@glixlur Auch dies bezieht sich auf Chromy / Headless Chrome: https://github.com/less/less.js/issues/3262

@glixlur In Bezug auf PhantomJS - diese Tests werden mit der gebündelten Browserversion ausgeführt, die Sie vermutlich in ES5 transpilieren würden, richtig? Warum funktioniert PhantomJS nicht mit dem ES5-Ausgabepaket?

@matthew-dean Ja, aber es gibt einen Fehler, bei dem Symbol verwendet wird, wenn PhantomJS mit einer Babel-transpilierten Datei ausgeführt wird.

@glixlur Sie benötigen das babel-polyfill in der transpilierten Ausgabe. Das ist ein guter Indikator dafür, dass es noch nicht richtig transpiliert. Siehe Probleme wie: https://github.com/babel/babel-preset-env/issues/203

@glixlur https://babeljs.io/docs/en/babel-polyfill/

@matthew-dean babel-polyfill fügt 87,3 KB verkleinert zur Ausgabedatei hinzu. Das willst du wahrscheinlich nicht.

@glixlur
Es gibt andere Gründe, warum Sie babel-polyfill nicht möchten. Nämlich die Tatsache, dass es den globalen Namensraum beeinflusst, indem es Polyfills auf window veröffentlicht und die Prototypen nativer Typen wie Array modifiziert.

Sehen Sie sich stattdessen das Paket babel-runtime und das Paket babel-plugin-transform-runtime an.

Außerdem arbeitet das iirc the Babel-Team daran, die Polyfills, die von transform-runtime gebündelt werden, auf die gleiche Weise wie die babel-env voreingestellten Sprachtransformationen zu begrenzen. Aber ihre Arbeit daran ist noch nicht abgeschlossen und allgemein verfügbar. Wäre am Ende ein Babel 7-Ding, das sowieso noch in der Beta ist, also nicht direkt brauchbar. Aber für die Zukunft auf jeden Fall wünschenswert.

@glixlur @rjgotten Ah. Ich hätte klarstellen sollen, dass ich nicht genau weiß, welche Lösung ich für Babel verwenden soll. Nur, weil Symbol undefiniert ist, weil es nicht polyfilled (ponyfilled?) ist, was es auch in IE11 wäre. Vielleicht ist es nicht das Polyfill, aber ich glaube, mit den richtigen Babel-Einstellungen sollte es Ihnen eine bereichsbezogene Symbol -Definition geben. Vielleicht ist es also die minimale Browserversion, die das Problem ist?

mit den richtigen Babel-Einstellungen sollte es Ihnen eine bereichsbezogene Symbol -Definition geben

Es wird in der Tat.
Diese Einstellungen laufen darauf hinaus, das Plugin transform-runtime zu verwenden und dessen Fähigkeit, Aliase für neuere integrierte Funktionen wie Symbol einzufügen, anstatt sich auf babel-polyfill zu verlassen.

Sollten Phantomjs veraltet sein?

In Anbetracht dessen, dass es tot ist?
Wahrscheinlich ja.

@glixlur Siehe: https://github.com/less/less.js/issues/3240

Konvertierung abgeschlossen und zusammengeführt! Siehe: https://github.com/less/less-meta/issues/32

Nun, diese Woche habe ich gelernt, dass Class in JavaScript NICHT einfach syntaktischer Zucker für Funktionsprototypen ist, was dieses Problem verursacht hat: https://github.com/less/less.js/issues/3414

Ironischerweise bin ich vor ungefähr 2 Wochen mit einem anderen Codestück, das nichts mit Less zu tun hat, auf genau dasselbe gestoßen, und ich erinnere mich deutlich an den Gedanken, der mich traf:

Meine Güte, ich frage mich, ob diese ES6-Konvertierung für Less diese Art von Problem verursachen würde.

Nun: Frage beantwortet, denke ich?

Ich beneide _so_ nicht den Sturm der Benutzer, die ihre Unzufriedenheit über Ihre Arbeit ausschütteten, @matthew-dean. Sie haben mein Mitgefühl, dass Sie mit dieser Situation umgehen müssen. :Lächeln:
Glücklicherweise scheint niemand apokalyptisch zu sein und es wurde ordentlich gehandhabt.

@rjgotten lol Ich meine, wie konntest du so etwas vorhersehen? Am sichersten wäre es gewesen, überhaupt nicht zu konvertieren oder niemals Klassen zu verwenden, aber es macht die Codebasis weniger ausführlich (nun, oder wird es möglicherweise, es gibt viele Möglichkeiten für weitere Aufräumarbeiten). Technisch gesehen hat die (historische) less-loader -Integration mit Less die API missbraucht (unter Verwendung einer undokumentierten/nicht unterstützten Verwendung der API), also war das ein Fehler ihrerseits, aber ich habe Verständnis dafür, dass die Leute darüber frustriert sind eine nicht-wichtige Punktveröffentlichung, die einen Build-Fehler verursacht.

Wenn zum Beispiel jemand die Prototypen in Ihrer Bibliothek hackt, wie codieren Sie dafür defensiv?

🤷‍♂

@rjgotten

Technisch gesehen habe ich nach der Konvertierung zwei Beta-Versionen veröffentlicht, ABER ... niemand hat Less-Betas in seiner Pipeline. Es gibt also keine Möglichkeit, 800.000 Repos zu testen, die in Less integriert sind, und ihre Tests auszuführen. Bei NPM-Abhängigkeiten müssen Sie es wirklich einfach veröffentlichen und sehen, was kaputt geht.

Eine Sache, die wir in Zukunft tun könnten, ist, einige größere Less-Abhängige zu Tests hinzuzufügen, wenn wir herausfinden können, was sie sind?

Das andere, was ich hätte tun können, wäre, es als Hauptversion zu veröffentlichen, aber .... es hat technisch gesehen KEINE (absichtlichen) Breaking Changes, dh die unterstützten Funktionen sind identisch, und es enthält einige Fehlerbehebungen, also ... .. Ich weiß nicht, das war eine schwierige Frage.

Ja. Es war eine knifflige Sache.

Ich denke, Sie hätten versuchen können, einfach etwas auf einem .next -Tag oder so zu veröffentlichen und die Leute darauf aufmerksam zu machen, ihre Build-Pipelines damit zu testen. Aber die Erfahrungen der Vergangenheit zeigen, dass so etwas im Allgemeinen ungehört bleibt.

So oder so, Hauptversion oder nicht, Sie würden wahrscheinlich gezwungen sein, es einfach zu versuchen und zu sehen, was kaputt geht.

Verstehen Sie mich aber nicht falsch: Das Refactoring ist eine sehr gute Sache. In Zukunft sollte es im Allgemeinen einen guten Teil der Wartungslast verringern.

Wenn zum Beispiel jemand die Prototypen in Ihrer Bibliothek hackt, wie codieren Sie dafür defensiv?

Du tust es buchstäblich nicht.

Es ist, als würden sich Leute darüber beschweren, dass ihre sorgfältig orchestrierte, zur Laufzeit ausgegebene IL für den Zugriff auf private Member in C# über kleinere Releases hinweg unterbrochen wird. Wenn Sie sich in Interna einmischen, sollten Sie wissen, worauf Sie sich einlassen. :Lächeln:

@rjgotten Apropos Refactoring ...

..... Eines der Dinge, die ich im Laufe der Zeit in der Less-Codebasis entdeckt habe, ist, dass es eine Reihe von Stellen gibt, an denen es leichte / subtile Mutationen an Objekten im AST gibt. Eine neue Eigenschaft hier / eine hinzugefügte Methode für eine Instanz dort, und ich gebe zu, dass ich dies manchmal mit Funktionen getan habe, die ich zusammengeführt habe, denn in JavaScript können Sie mutieren, was immer Sie wollen, wann immer Sie wollen, ob Sie diese Eigenschaft dokumentiert/definiert oder nicht.

Es gab einige Diskussionen darüber, ob TypeScript oder nur modernes JS die Antwort sein würden oder nicht. Ich habe festgestellt, dass das Fehlen von Typen oder klaren Objektschnittstellen es manchmal sehr schwierig macht, über die Codebasis von Less nachzudenken, so dass keine Menge an Dokumentation oder sogar JSDocs sie lösen könnte.

Ich habe die neue Pipeline so eingerichtet, dass TypeScript Linting zulässt, _wenn_ Sie die richtigen Typen in JSDoc haben, aber die Verwendung von JSDoc zum Tippen ist viel ausführlicher / visuell lauter als TypeScript, und es gibt einige Tippfunktionen, die TS einfach nicht über JSDoc-Anmerkungen allein unterstützt . Es gibt keine JSDoc / ESLint-Kombination von Tools, die einige dieser Probleme lösen können, die TS Ihnen kostenlos zur Verfügung stellt.

Also, ich denke, alles, was ich sagen will, ist, dass ich nach der intensiven Nutzung von TypeScript im letzten Jahr und Jahren in der Less-Codebasis sagen würde, dass ich sagen würde, dass 95 % der Verwirrung/Frustration/Lernkurve darin bestehen, herauszufinden, wie Less funktioniert wurden vermieden, wenn für Objekte Typen zur Kompilierzeit erzwungen wurden. Ich habe oft viel Zeit in einem Debugger damit verbracht, nur Haltepunkte zu setzen und herauszufinden, was die Eigenschaften eines Objekts _eigentlich_ sind, anstatt wie es in einer Datei definiert ist.

Zum Beispiel gibt es eine Reihe von Features, die Less hat, die sich während der Auswertung auf die paths -Eigenschaft eines Ruleset -Knotens verlassen. Können Sie mir anhand dieses Konstruktors sagen, was die Eigenschaft paths ist und welche Form sie haben wird? (Hinweis: Sie können nicht, weil es nicht da ist.)

In TypeScript (mit allgemeinen tsconfig-Einstellungen) wäre dies nicht zulässig. Es würde nicht einmal kompilieren. Sie wären gezwungen, die Form von paths anzugeben und genau, was darin enthalten wäre, was dann wiederum jemandem, der die Codebasis untersucht, eine klare, spezifische Dokumentation (und Codehinweise) geben würde.

Ich denke, an diesem Punkt bin ich von dem Gedanken „TypeScript ist etwas, das man in Betracht ziehen sollte“ zu dem Gefühl übergegangen, „Wenn Ihr öffentliches Projekt nicht in TypeScript ist, haben Sie eine große technische Schuld.“ Ich würde niemals ein Open-Source-Repo ohne es starten, da es von Natur aus dazu beiträgt, die Konsumfähigkeit und Wartbarkeit zu lösen. Sie brauchen immer noch eine klare Dokumentation, aber zumindest erzwingt sie eine extrem klare und zusammenhängende Codierung.

Das bin nur ich, der darüber nachdenkt, wie es weitergehen soll und wie man Schmerzpunkte in Zukunft vermeiden kann.

_( Nachtrag : Falls es nicht klar ist, ich schlage zu 100 % nicht auf die historische Arbeit von irgendjemandem in der Less-Codebasis ein. Es gibt eine Menge Dinge, die ich vorgeschlagen, Zustimmung erhalten und in die Codebasis zusammengeführt habe, die ich jetzt Ich sage: „Oof, ich wünschte, ich hätte das nicht getan“ oder wünschte, ich hätte es anders gemacht. Und ich habe sicherlich Dinge hinzugefügt, von denen ich jetzt erkenne, dass sie sich negativ auf die Wartbarkeit ausgewirkt haben könnten. Jeder hat sein Bestes gegeben.)_

@matthew-dean
Ich habe die neue Pipeline so eingerichtet, dass TypeScript-Linting zugelassen wird, wenn Sie die richtigen Typen in JSDoc haben, aber die Verwendung von JSDoc zum Tippen ist viel ausführlicher / visuell lauter als TypeScript, und es gibt einige Tippfunktionen, die TS einfach nicht über JSDoc-Annotationen allein unterstützt . Es gibt keine JSDoc / ESLint-Kombination von Tools, die einige dieser Probleme lösen können, die TS Ihnen kostenlos zur Verfügung stellt.

Tatsächlich; Ich bin auch auf das Problem gestoßen, dass die JSDoc-Unterstützung für die Typinferenz so lala ist.
Glücklicherweise können Sie .d.ts -Deklarationsdateien neben .js -Quelldateien verwenden, ohne dass Sie sich voll auf TypeScript verlassen müssen und den Compiler benötigen.

Früher war es viel schwieriger, mit Deklarationsdateien zu arbeiten, aber moderne Versionen des TypeScript-Compilers verknüpfen automatisch eine .d.ts -Datei nebeneinander mit einer .js -Datei, solange beide benannt sind das gleiche.

Das könnte das sein, was Sie suchen.

@rjgotten Können Sie etwas mehr erklären (oder verlinken, wenn Sie eine gute Ressource kennen), wie dies mit der Codebasis von Less gut funktionieren könnte? Wie machen Sie das auf Dateiebene? Gibt es eine .d.ts -Datei pro .js -Modul? Oder gruppierst du sie?

Was sind die Vorteile einer .d.ts -Datei gegenüber der Verwendung von TypeScript in der Quelle? Warum die Zeit damit verbringen, .d.ts -Dateien zu erstellen, anstatt nur diese Typen in den Dateien zu definieren?

@rjgotten Ich habe heute mit dem Entwickler von Chevrotain gesprochen, und er sagt, er entwickelt in TS _ABER_ er verwaltet tatsächlich eine api.d.ts -Datei als separates Anliegen. Auf diese Weise ändern alle Änderungen von Typen in den Quelldateien (z. B. Baumknoten) die öffentliche API nicht transparent / unsichtbar, ohne dass die API-Typendatei explizit geändert wird.

Dann verwendet er einen Test mit einer Behauptung, dass die internen Typen und die öffentlichen API-Typen übereinstimmen -> https://github.com/SAP/chevrotain/blob/master/packages/chevrotain/test_integration/definitions/api_type_checking.ts#L1 - L2

Der Weg von Chevrotain ist ein guter Weg, um zu erzwingen, dass sich Ihre öffentliche API nicht versehentlich ändert. Sehr robust, wenn Sie glauben, dass Sie dieses Maß an Schutz benötigen. Aber auch etwas Overhead.

In Bezug auf die Verwendung von .d.ts -Deklarationsdateien zum Speichern von .js -Typisierungen:
Es ist eigentlich beides.

Wenn sie nebeneinander liegen, wird jede IDE, die vom TypeScript-Compiler für automatische Vorschläge, Linting usw. unterstützt wird, automatisch die Eingaben übernehmen. Afaik _auch_ wenn diese Skripte mit Side-by-Side-Eingaben von node_modules importiert werden, was ganz nett ist.

Sie können auch Typisierungen in eine einzelne (Gruppe von) .d.ts -Datei(en) wie api.d.ts einfügen und dann JSDoc verwenden, um die deklarierten Typen explizit zu importieren. Die JSDoc-Unterstützung in TypeScript hat dafür eine spezielle Variante von @typedef mit Importsyntax. Z.B

/**
 * <strong i="17">@typedef</strong> {import("../api.d.ts").MyType } MyType
 */

Die Verwendung einer einzigen gebündelten Typisierungsdatei ist eine gute Idee, wenn Sie Ihr Paket vor der Verteilung durch einen Transpiling-Schritt führen müssen. In einem solchen Fall werden die Benutzer tatsächlich require() oder import {} nicht mehr die ursprünglichen Quelldateien sein. Dh sie würden nicht von Side-by-Side-Schreiben profitieren.