eslint zeigt Fehler

[heinetz]

Hallo Forum,

eslint zeigt mir noch zwei Fehler an in folgender Funktion:

  static isExternalUrl(url) {
    function domain(url) {
      const a = document.createElement('a');
      a.href = url;
      return a.hostname;
    }
    return domain(location.href) !== domain(url);
  }

error 'url' is already declared in the upper scope error Unexpected use of 'location'

Kann mir jemand verraten, wie ich das sinnvoll behebe?

100Dank für Tipps und

beste gruesse, heinetz

[1unitedpower]

Olla!

  static isExternalUrl(url) {
    function domain(url) {
      const a = document.createElement('a');
      a.href = url;
      return a.hostname;
    }
    return domain(location.href) !== domain(url);
  }

error 'url' is already declared in the upper scope

Die beiden Funktionen isExternalUrl und domain haben beide einen Parameter namens url. Das kreidet eslint an. Lösungen könnten sein, die Funktion domain in den äußeren Scope zu verlagern, oder einen der beiden Parameter umzubenennen.

error Unexpected use of 'location'

location ist eine globale Variable, eslist will vermutlich, dass du das explizit machst, also window.location oder besser document.location.

Btw: Der Umweg über document.createElement('a') ist heutzutage nicht mehr notwendig, du kannst auch new URL('https://example.com').hostname benutzen.

[Christian Kruse]

Hallo 1unitedpower,

Btw: Der Umweg über document.createElement('a') ist heutzutage nicht mehr notwendig, du kannst auch new URL('https://example.com').hostname benutzen.

Der Vollständigkeit halber: siehe auch caniuse.com.

LG,
CK

[Rolf B]

Hallo 1unitedpower,

Ist eslint da nicht sehr penibel? Ein error, weil ich eine Variable überlagere? Eine Warnung oder einen Hinweis würde ich verstehen.

Rolf

[1unitedpower]

Ist eslint da nicht sehr penibel? Ein error, weil ich eine Variable überlagere? Eine Warnung oder einen Hinweis würde ich verstehen.

eslint ist ja keine Laufzeit-Umgebung, deswegen würde mir jetzt kein besonderer Vorteil einfallen, für die verschiedene Abstufungen von Fehlermeldungen sorgen würden. Was sollte denn deiner Meinung nach anders sein? Du kannst als Entwickler übrigens in deiner eslint-Konfiguration selbst bestimmen, welche Regeln eingehalten werden müssen. Konkret handelt es sich hier um die Regel no-shadow, die Dokumentation liefert eine kleine Begründung dazu, wann und warum diese Regel sinnvoll ist. Das ist zunächst mal eine kleine Hilfestellung, anhand derer man entscheiden kann, ob sie für den konkreten Anwendungsfall zweckmäßig ist.

[Rolf B]

Hallo 1unitedpower,

Ein Linter kann auch den Zweck haben, die Einhaltung bestimmter Codestyles zu überwachen. Und da kann man zwischen MUSS, SOLL und KANN unterscheiden, insofern sind Schweregrade schon sinnvoll.

Ein Error würde einen Build-Prozess abbrechen und damit einen Deploy verhindern, eine Warning nicht.

Rolf

[1unitedpower]

Ein Error würde einen Build-Prozess abbrechen und damit einen Deploy verhindern, eine Warning nicht.

Mhm, ich verstehe dein Anliegen. Das kannst du mit eslint trotzdem erreichen, indem du verschiedene Konfigurationen für verschiedene Entwicklungsphasen benutzt. Also bspw. für ein Deployment-Build eine andere Konfiguration als für die lokale Entwicklungsumgebung oder die CI-Pipeline. Entwicklungsrozesse unterscheiden sich ja je nach Projekt sehr stark voneinander, vielleicht ist es daher auch eine bewusste Entscheidung von eslint keine Vorgaben diesbezüglich zu machen, sondern einfach die nötige Flexibilität zu liefern.

[dedlfix]

Tach!

Ist eslint da nicht sehr penibel?

Genau das ist die Aufgabe eines Linters. Der zeigt auf Fehler und auf problematische Stellen, selbst auf Abweichungen vom Coding Style, wenn gewünscht.

Ein error, weil ich eine Variable überlagere?

Kann ja ungewollt sein.

dedlfix.