Node.js und Firebase

[Casablanca]

Hi,

kennt sich hier jemand mit node.js und firebase aus? Ich bekomme beim deployen von async Funktionen diese Fehlermeldung: "Parsing error: Unexpected token =>"

Danke

[Staufer]

Hi,

kennt sich hier jemand mit node.js und firebase aus? Ich bekomme beim deployen von async Funktionen diese Fehlermeldung: "Parsing error: Unexpected token =>"

Bei SO hast Du wsl schon geschaut.

Hier gibt's was für ESLint: Error with async: "Parsing error: Unexpected token =>"

Async functions are an ES2017 (or "ES8") feature, but you have ecmaVersion: 7 in your config. To fix this, you should use ecmaVersion: 8 or ecmaVersion: 2017 in your config.

Mfg Staufer

[Casablanca]

Hallo Staufer,

vielen Dank. Das war es. Ich habe gestern den halben Tag mit diesem Problem herumhantiert. Ich verstehe nicht, warum node.js/Firebase mit so etwas substanziellem wie async Probleme haben müssen.

LG

[Rolf B]

Hallo Casablanca,

ich hatte mich zurückgehalten, weil ich nur vage Vermutungen anstellen konnte und deinen Workflow nicht kenne.

Aber wenn ich das jetzt richtig lese, kommt die Meldung von ESLint, und dem musst Du schon sagen, welche Sprachstufe er prüfen soll. So ein Tool soll ja Fehler finden, die sonst erst zur Laufzeit auffallen würden.

Async gehört zu ECMAScript 2017 (sagt auch Kangax) und gerade bei node.js laufen noch viele Alt-Server herum. Deswegen mag es sinnvoll sein, dass dieser Sprachlevel per Default aus ist und Du ihn explizit aktivieren musst.

Rolf

[Casablanca]

Hallo Rolf,

danke für deine hilfreiche Erklärung.

Ich bin alleine nicht darauf kommen können, zumal die Fehlermeldung für mich als Starter nicht eindeutig war. Ich wusste nämlich nicht genau, ob ich da was falsch programmiert habe, oder darf ich an dieser Stelle überhaupt kein async einsetzen.

LG

[Rolf B]

Hallo Casablanca,

ja, die Fehlermeldung ist totaler Blödsinn. Pfeilfunktionen gibt's schon so lange, dass sie beinahe schon im IE funktionieren (aber nur beinahe), insofern ist nicht verständlich warum er sich über => aufregt.

Aber wenn Du ihm sagst:

let stupid = async (x) => x+1;

und einen JS Parser dran lässt, dem man nichts von async verraten hat, dann denkt der, dass da eine Funktions namens async aufgerufen wird. Die ergibt irgendeinen Wert, und auf den möchte man nun einen => Operator anwenden? No, Sir, that's not possible, Sir.

Das zeigt, dass ESLint durchaus Nachbesserungsbedarf hat. Es reicht nicht, die neueren Sprachkonstrukte einfach aus der Grammatik herauszunehmen. Man muss sie drin haben und dann erkennen, dass das einen bestimmten Sprachlevel vorausetzt.

Ich habe tatsächlich keine Ahnung, ob die dark corners von JavaScript so finster sind, dass ein total legales und funktionierendes Konstrukt in Version X durch eine Veränderung in Version X+1 plötzlich etwas ganz anderes tut, weil ein neues Feature es umdeutet. Ich hoffe, dass das nicht so ist.

Rolf

[dedlfix]

Tach!

Das zeigt, dass ESLint durchaus Nachbesserungsbedarf hat. Es reicht nicht, die neueren Sprachkonstrukte einfach aus der Grammatik herauszunehmen. Man muss sie drin haben und dann erkennen, dass das einen bestimmten Sprachlevel vorausetzt.

Naja, dann müsste man jeden alten Linter/Parser an alle neu erscheinenden Sprachversionen anpassen, so dass er nicht nur Syntaxfehler gemäß dem alten Stand bemängelt, sondern auch noch errät, welches Feature aus welcher neuen Sprachversion man gemeint haben könnte. Das halte ich für zu aufwendig.

dedlfix.

[dedlfix]

Tach!

Ich bekomme beim deployen von async Funktionen diese Fehlermeldung: "Parsing error: Unexpected token =>"

Bei SO hast Du wsl schon geschaut.

Hier gibt's was für ESLint: Error with async: "Parsing error: Unexpected token =>"

Das unexpected Token ist aber nicht async, sondern der Fat Arrow. Dass der Fehler im Zusammenhang mit async auftritt, ist eher Zufall. Wahrscheinlich werden in seinem Code nur dort Arrow Function Expressions verwendet.

Async functions are an ES2017 (or "ES8") feature, but you have ecmaVersion: 7 in your config. To fix this, you should use ecmaVersion: 8 or ecmaVersion: 2017 in your config.

Vermutlich hatte er ES5 voreingestellt, das wäre ein üblicher Wert, weil damit auch ältere Systeme noch zurechtkommen. Arrow Function Expressions kamen bereits mit ES6/ES2015.

dedlfix.

[Rolf B]

Hallo dedlfix,

Dass der Fehler im Zusammenhang mit async auftritt, ist eher Zufall.

Nein, ich denke nicht. Guckst Du

(Edit - damn, Hash-Part als Link genügt alleine nicht 😂)

Rolf

[dedlfix]

Tach!

Dass der Fehler im Zusammenhang mit async auftritt, ist eher Zufall.

Nein, ich denke nicht. Guckst Du

Na gut, in deinem Beispiel beklagt sich nur der ES2015-Linter mit der Meldung aus dem OP. Der ES5 würde sich schon am let stören. Aber wenn wir da mal var nehmen, gefällt ihm an dem Konstrukt ein "Assigning to rvalue" nicht. Und ohne das async beklagt er sich nur über ein unerwartetes > (ohne =).

dedlfix.

[Rolf B]

Hallo dedlfix,

Der ES5

wurde jetzt von Dir ins Spiel gebracht und war bisher auf der Veteranentribüne...

Sogar der IE11 kann schon let. Fast das einzige ES6, was er gelernt hat. Und was der kann, kann man als universell nutzbar ansehen 😉

Staufers Hinweis bezog sich aber auf ES7 (aka 2016) vs ES8 (aka 2017).

Und ich hatte mein "ESLint muss dazulernen" auch anders gedacht. Wenn ich einen Linter herausbringe, der bis hin zu ECMAScript 2017 oder vielleicht auch mehr beherrscht, und ihm eine Option wie „JS Konstrukte sind nur bis ECMAScript 2016 zulässig“, dann ist ein stumpfes dumb-down auf den ECMAScript 2016 Parser eine zu einfache Lösung.

Die aufwändige Lösung ist ein ECMAScript Parser für den aktuellen Sprachlevel, der jedes erkannte Sprachkonstrukt mit "valid in ES.x" markiert und ggf. auch "deprecated in ES.y", und nachdem der durch ist, durchsucht ESLint den gefundenen AST nach Sprachmarkierungen, die für den gewünschten Ziellevel zu hoch sind.

Die billigere Lösung wäre, für jeden Sprachlevel einen Parser aufzubewahren, mit dem Parser für den gewünschten Level zu beginnen, und bei gefundenen Fehlern so lange auf den nächsthöheren Level zu wechseln, bis der Fehler weggeht. In Casablancas Fall hätte er - mutmaßlich - mit ES7 begonnen, den Parser Error bekommen, es mit ES8 nochmal probiert, das Weggehen des Fehlers festgestellt und dann sagen können: Sorry, ECMAScript 2017 Feature, you wanted only ECMAScript 2016.

Und wenn der Fehler nicht weggeht, kann er immer noch „That's tommy-rot in line 4711“ ausgeben...

Rolf

[Casablanca]

Hi,

danke. Ich habe die Arrow-Funktion auch in den anderen Bereichen. Der Parser meckert sich hierbei aber nur in Verbindung mit async. Wie bereits erwähnt, halte ich async als Sprach-Funktion mittlerweile als substanziell genug, um diese direkt beim parsen zu berücksichtigen. Man führt auch keine Einstellungen für foreach, if und derartiges.

LG

[dedlfix]

Tach!

Wie bereits erwähnt, halte ich async als Sprach-Funktion mittlerweile als substanziell genug, um diese direkt beim parsen zu berücksichtigen.

Dann übersiehst du aber, dass noch genügend alte Systeme in Verwendung sind, die die neue Syntax nicht kennen. Für diese muss man alten Code erzeugen oder Syntax gemäß alter Regeln prüfen.

Eigentlich bist du als Programmierer selbst dafür verantwortlich, dass du auch deine Tols kennst, und sie richtig konfigurierst. In der Wirtschaft ist man oft sehr konservativ, und so ist auch bei der Softwareentwicklung meist noch sehr lange die Kompatibilität mit alten Systemen die Defaulteinstellung.

Man führt auch keine Einstellungen für foreach, if und derartiges.

foreach gibt es in Javascript nicht, aber das dortige Äquivalent hat auch eine Historie hinter sich und ist nicht in allen Versionen gleichermaßen vorhanden.

Wie auch immer, es hilft nicht, darüber zu lamentieren, wenn etwas deinen Erwartungen nicht entspricht. Wichtig ist, dass du zu den verwendeten Features prüfst, ob deine Tools auf sie eingestellt sind. Und andererseits, ob die Zielsysteme damit klarkommen, oder du eine frühere Version anbieten muss, dann aber auf aktuellere Features verzichtest.

dedlfix.