Jsdom: jest : SecurityError: localStorage ist für undurchsichtige Ursprünge nicht verfügbar

Zusammenfassung der folgenden Diskussion:

• Der Fix besteht darin, eine URL für Ihr jsdom festzulegen, was möglicherweise über Ihre Testumgebungskonfiguration erfolgen muss. Die Standard-URL " about:blank " verursacht Fehler beim Versuch, auf localStorage zuzugreifen.
• Die Hauptursache sind oft Bibliotheken, die alle jsdom-Eigenschaften durchlaufen und sie der globalen hinzufügen; selbst wenn Sie localStorage nie in Ihren Tests verwenden, "verwenden" Sie eine Bibliothek oder ein Test-Framework, auf das Sie angewiesen sind, auf diese Weise. Beachten Sie, dass diese Schleifen-und-Kopieren-Technik explizit nicht unterstützt wird , daher ist es nicht verwunderlich, dass Code, der dies tut, in einer Nebenversion kaputt gehen könnte.

Transkription des folgenden Kommentars zur Frage, ob dies eine "breaking change" ist, die seitdem von GitHubs "see more comments"-Funktion ausgeblendet wurde:

Danke, aber zum jetzigen Zeitpunkt glaube ich nicht, dass dies der beste Weg ist. Es ist keine bahnbrechende Änderung für jsdom, neue Webplattform-Features zu implementieren; das ist eine Nebenversion.

Abhängige, sogar weit verbreitete Abhängige, können unglücklichen Code schreiben, der neue Funktionen erkennt und eine Ausnahme auslöst, wenn sie auftreten. Ich hoffe, wir sind uns alle einig, dass jsdom, selbst wenn es solche Abhängigkeiten gibt, nicht für immer aufgeben sollte, neue Funktionen in Nebenversionen hinzuzufügen.

Die Situation hier ist nicht ganz so drastisch, scheint aber ähnlich zu sein. Ich habe noch niemanden gesehen, der den anstößigen Jest-Code aufgespürt hat, daher ist es schwer genau zu sagen, aber es scheint, dass er eine Operation durchführt, die ausdrücklich durch den normalen Verlauf der jsdom-Entwicklung unterbrochen wird und die in einem Web nicht funktionieren würde Browser, der localStorage implementiert.

Mir ist klar, dass dies eine schwierige Situation für diejenigen von Ihnen ist, die ohne eigenes Verschulden von einer unglücklichen Interaktion darüber betroffen sind, wie Ihre direkte Abhängigkeit Ihre indirekte Abhängigkeit (missbraucht) nutzt. Aber ich hoffe, dass dies auf der richtigen Ebene angegangen werden kann, indem Jests fehlerhafter Code behoben wird, anstatt eine nützliche Funktion aufgrund der Fehler eines abhängigen Benutzers von allen jsdom-Benutzern zu entfernen.

Ursprüngliche Antwort an das OP, für den Kontext:

Wahrscheinlich legen Sie in Ihren Tests keine URL fest, aber Sie oder vielleicht Jest greifen auf window.localStorage . Die Betreuer von Jest wissen vielleicht mehr über die beste Lösung, aber ich habe gehört, dass es eine Möglichkeit gibt, URLs in Ihren Jest-Tests festzulegen?

Dies ist ein sehr aktuelles Problem, das mit 11.12.0 aufgetaucht zu sein scheint. Ich erhalte dieselben Fehler, wenn ich jest mit enzyme .

Ja, das Problem trat nach dem Upgrade von 11.11.0 auf 11.12.0 . Das Festlegen von testURL in der Jest-Konfiguration behebt das Problem.

@ben-mckernan Hallo, wie lautet die URL, die Sie angegeben haben, um das Problem zu beheben?

@gokulkrishh Ich habe es auf http://localhost/ aber jede gültige URL scheint zu funktionieren.

Ich denke, dies ist wahrscheinlich enzymspezifisch , weil Enzyme

Bei mir ist das auch kaputt gegangen :(

@ben-mckernan Danke 👍

Auch dies erleben.

https://github.com/jsdom/jsdom/blob/23d67ebec901b3471b84e63f58a96b51a36f3671/lib/jsdom/browser/Window.js#L255

("+1"-Kommentare werden als Spam markiert; E-Mails an alle im Problem-Thread zu senden ist nicht hilfreich.)

Entschuldigung. Ich versuche nur zu helfen.

Kann das Hinzufügen von testURL zu jestConfig bestätigen, wie @ben-mckernan vorgeschlagen hat, es behoben zu haben.

Und wir verwenden auch Enzyme, wenn das Ihre Intuition bestätigt.

Für den Elektron-App-Test habe ich es einfach auf "file:/" gesetzt, was auch funktioniert.

@miamollie Ich habe testURL gemäß dem Vorschlag von @ben-mckernan hinzugefügt (Verwendung von Jest + Enzyme, nicht sicher, ob es sich um ein Enzym handelt. Fehler von jest-environment-jsdom , das jsdom verwendet). Aus diesem Grund schlagen meine anderen Testdateien fehl. Nur zu deiner Information. Sehen Sie, ob es für Sie funktioniert. Ihre Testfälle können sich von meinen unterscheiden (TestURL könnte für Sie funktionieren).

@domenic Ich

@gokulkrishh Ja, es hat den localStorage-Sicherheitsfehler gestoppt, aber einige andere Tests sind fehlgeschlagen.

@ben-mckernan Lösung hat es behoben. Vielen Dank!

@ben-mckernan Ich verwende Jest in einem Winkel-Setup (mit Jest-Preset-Angular), gleicher Fehler, gleiche Lösung. Es ist also kein Enzymproblem.

Scheint, als müsste Jest den Standardwert von testURL ändern, damit dies gemildert wird (derzeit ist es about:blank ).

@DcsMarcRemolt Ich habe das Problem gerade Jest verwendet ein Abhängigkeitsmodul namens jest-environment-jsdom in seinem package.json --> "jsdom": "^11.5.1" caret(^) wegen diesem npm haben jsdom als 11.12.0 installiert (das ist die neue Version, die heute veröffentlicht wurde). Also ist es bei den meisten Benutzern kaputt gegangen. Ausgabe ist bereits im Scherz erstellt und hier verlinkt. Achten Sie darauf.

Ich werde dieses Problem erneut öffnen, um es sichtbarer zu machen. Eine Lösung finden Sie im ersten Kommentar von Domenic.

Folgendes zur jest-Konfiguration in package.json hinzufügen:
"testEnvironment": "node"
löst das Problem bei mir.
Danke an Problems .

Ich kann die JSDOM-Implementierung auf localStorage seit diesem Update nicht mehr überschreiben und verspotten.

Da dies für viele Leute eine unbeabsichtigte Breaking Change war, wäre vielleicht die beste Option zur Schadensbegrenzung:

• Machen Sie diese Änderung rückgängig.
• Geben Sie Version 11.12.1 mit der rückgängig gemachten Änderung frei, um das erwartete Verhalten wiederherzustellen.
• Ziehen Sie die Version 11.12.0 mit einer Warnung herunter oder verwerfen Sie sie.
• Wenn das neue Verhalten unverändert gewünscht wird, lassen Sie 12.0.0 um anzuzeigen, dass es eine Breaking Change gibt.

Danke, aber zum jetzigen Zeitpunkt glaube ich nicht, dass dies der beste Weg ist. Es ist keine bahnbrechende Änderung für jsdom, neue Webplattform-Features zu implementieren; das ist eine Nebenversion.

Abhängige, sogar weit verbreitete Abhängige, können unglücklichen Code schreiben, der neue Funktionen erkennt und eine Ausnahme auslöst, wenn sie auftreten. Ich hoffe, wir sind uns alle einig, dass jsdom, selbst wenn es solche Abhängigkeiten gibt, nicht für immer aufgeben sollte, neue Funktionen in Nebenversionen hinzuzufügen.

Die Situation hier ist nicht ganz so drastisch, scheint aber ähnlich zu sein. Ich habe noch niemanden gesehen, der den anstößigen Jest-Code aufgespürt hat, daher ist es schwer genau zu sagen, aber es scheint, dass er eine Operation durchführt, die ausdrücklich durch den normalen Verlauf der jsdom-Entwicklung unterbrochen wird und die in einem Web nicht funktionieren würde Browser, der localStorage implementiert.

Mir ist klar, dass dies eine schwierige Situation für diejenigen von Ihnen ist, die ohne eigenes Verschulden von einer unglücklichen Interaktion darüber betroffen sind, wie Ihre direkte Abhängigkeit Ihre indirekte Abhängigkeit (missbraucht) nutzt. Aber ich hoffe, dass dies auf der richtigen Ebene angegangen werden kann, indem Jests fehlerhafter Code behoben wird, anstatt eine nützliche Funktion aufgrund der Fehler eines abhängigen Benutzers von allen jsdom-Benutzern zu entfernen.

Danke fürs klarstellen. Ich stimme zu, dass, wenn das Problem durch die nicht unterstützte Verwendung von jsdom wie oben beschrieben verursacht wird, es technisch gesehen keine Verletzung des Servers ist und Jest einen Patch veröffentlichen sollte.

Meine Problemumgehung, verwenden Sie eine Blacklist, wenn Sie alle jsdom- Eigenschaften

const { JSDOM } = require('jsdom');
const Node = require('jsdom/lib/jsdom/living/node-document-position');

// We can use jsdom-global at some point if maintaining these lists is a burden.
const whitelist = ['HTMLElement', 'Performance'];
const blacklist = ['sessionStorage', 'localStorage'];

function createDOM() {
  const dom = new JSDOM('', { pretendToBeVisual: true });
  global.window = dom.window;
  global.Node = Node;
  global.document = dom.window.document;
  // Not yet supported: https://github.com/jsdom/jsdom/issues/317
  global.document.createRange = () => ({
    setStart: () => {},
    setEnd: () => {},
    commonAncestorContainer: {
      nodeName: 'BODY',
      ownerDocument: document,
    },
  });
  global.navigator = {
    userAgent: 'node.js',
  };

  Object.keys(dom.window)
    .filter(key => !blacklist.includes(key))
    .concat(whitelist)
    .forEach(key => {
      if (typeof global[key] === 'undefined') {
        global[key] = dom.window[key];
      }
    });
}

module.exports = createDOM;

Stecken Sie keine jsdom-Globals auf den Node-Global

Nun, ich passe vorerst. Ich brauche die Tests, um in jsdom und in echten Browsern ausgeführt zu werden. Es ist der einfachste Ansatz, den ich mir vorstellen kann, er funktioniert seit Jahren. In den vorgeschlagenen Alternativen sehe ich nicht das gleiche Potenzial.
Die Verwendung von jsdom-global könnte auch funktionieren.

Nun, ich passe vorerst. Ich brauche die Tests, um in jsdom und in echten Browsern ausgeführt zu werden.

Wenn Ihre Tests in "echten Browsern" ausgeführt werden können, können sie auch in jsdom auf die gleiche Weise ausgeführt werden - stellen Sie einfach den gleichen HTML-Code bereit. Durch die Zuweisung zum Globalen führen Sie stattdessen zusätzliche Komplexität und Unterschiede im Vergleich zur Ausführung des Tests in einem Browser ein.

Zu Ihrer Information Ich habe das gleiche Problem mit Mocha, nicht mit Jest, nachdem ich jsdom auf 11.12.0 aktualisiert habe.

Hallo, ich möchte nur verstehen, warum die Änderungen an erster Stelle eingeführt werden.

Meine Anwendungsfälle bestehen einfach darin, eine Funktion zu bestätigen, um sicherzustellen, dass ich sie richtig geschrieben habe. Es ist so einfach wie:

const fib = require('./index');

test('Fib function is defined', () => {
  expect(typeof fib).toEqual('function');
});

test('calculates correct fib value for 1', () => {
  expect(fib(1)).toEqual(1);
});

und doch scheint das Testergebnis Fehlermeldungen zu sein, dass ich gerade eine große Anwendung auf React mit der Redux-Bibliothek und ähnlichem gemacht habe, während ich in Wirklichkeit einfach eine so einfache Funktion wie teste

//index.js, yes, only one line, no react no redux no enzyme 
function add(a, b) {}

Übrigens, testURL und testEnvironment "hack" funktionieren bei mir nicht. Dies ist meine package.json:

    "jest": {
        "testURL": "http://localhost/",
        "testEnvironment": "node"
    },

Meine Frage ist also, warum die ganze Mühe, Breaking Changes einzuführen, während wir manchmal nur einen Testläufer wollen, der einfach "funktioniert"

@khmy2010 Ihr Code und Ihre Fragen beinhalten mehr Jest als jsdom. Ich würde vorschlagen, dass Sie stattdessen ein Problem in ihrem Repository erstellen.

Dieselbe Fehlermeldung mit der Op und fast allen hier (außer ich bin es nicht)
unter Verwendung von Enzymen). Wenn nichts damit zu tun hat, sollte ich scherzhaft ein Thema eröffnen. Entschuldige wegen
das.

Am 30. Juli 2018 um 21:32 Uhr schrieb "Zirro" [email protected] :

@khmy2010 https://github.com/khmy2010 Ihr Code und Ihre Fragen beinhalten
Witze mehr als sie jsdom tun. Ich würde vorschlagen, dass Sie ein Problem in ihrem erstellen
Repository https://github.com/facebook/jest stattdessen.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/jsdom/jsdom/issues/2304#issuecomment-408864079 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AVrB3uOLy7l4JKbStKWPtGi0oHfAaQbYks5uLwrpgaJpZM4Vi8gP
.

Wenn Sie Ihre jsdom Instanz erstellen, können Sie eine benutzerdefinierte URL als zweiten Parameter übergeben:

const url = 'http://localhost';
const jsdom = new JSDOM('<!doctype html><html><body></body></html>, { url });

Dies könnte nützlich sein, wenn Sie Enzyme + Mocha @srodrigo verwenden

Dadurch wurde die bestehende Infrastruktur zerstört. Dies sollte die Hauptversion 12.0.0 und nicht die Nebenversion 11.12.0 sein. Minor-Releases sollten bestehenden Code nicht beschädigen.

Domenic erklärt in diesem Kommentar (wenn es beim Klicken auf den Link nicht angezeigt wird, scrollen Sie nach oben und laden Sie die versteckten Kommentare), warum dies nicht als Breaking Change angesehen wurde. Der Code von abhängigen Paketen, der Dinge tut, von denen wir jahrelang abgeraten haben, wird hoffentlich bald von ihren Betreuern repariert.

Zusätzlich zum obigen Fix musste ich dies zum Stammverzeichnis der Testkonfiguration hinzufügen: --env=jsdom

Folgendes zu meiner jest.config.js hinzufügen

testURL: 'http://localhost',

Problem gelöst. Vielen Dank!

(Jest Betreuer hier.) Halten Sie es aus Jests Sicht für sinnvoll, vom Standard about:blank auf zB localhost zu ändern?

Ich bin mir nicht sicher, ob ich schlau genug bin, meine Meinung dazu zu äußern, aber aus Entwicklersicht würde ich sagen, dass localhost sinnvoller ist, about:blank ist ein Fall, der nie Realität wird. Wir testen unsere Apps, die praktisch nie about:leere URLs haben

Das Jest-Team hat einen intelligenteren Standardwert für testURL hinzugefügt: https://github.com/facebook/jest/pull/6792

@SimenB Ich würde sagen, das ist eine gute Idee.

Bekomme den gleichen Fehler wie das OP, aber in meiner Situation hat es viele Probleme verursacht. Wir sperren die Versionen der von uns verwendeten Pakete und können sie nur zu Beginn eines Release-Zyklus ändern. Wir nähern uns derzeit dem Ende des Release-Zyklus, daher haben unsere Entwicklerumgebungen die Versionen aller Pakete und deren Abhängigkeiten von etwa einem Monat, aber als wir den Build-Server einen Build erstellen ließen, griff er auf die aktuelle Version von allen zurück Pakete. Während also alle Tests lokal erfolgreich sind, schlagen sie alle auf dem Build-Server fehl.

Wir verwenden die Option "setupTestFrameworkScriptFile" in der jest-Konfigurationsdatei, um einige Einstellungen vorzunehmen, einschließlich Polyfills für (unter anderem) localStorage und sessionStorage (da wir beide in unserer App verwenden). Es ist im Grunde window.localStorage = window.localStorage || { ... } , und das gleiche gilt für sessionStorage, wo ... eine Reihe von Scheinfunktionen ist. Jetzt funktioniert nichts davon, auch wenn ich es so ändere, dass es immer die Standardeinstellung überschreibt ( window.localStorage = { ... } ).

Darüber hinaus haben wir Unit-Tests, die speziell testen, ob sessionStorage.getItem aufgerufen wird, aber nachdem "testURL" auf " http://localhost " gesetzt wurde, wie oben empfohlen, um die localStorage-Fehler zu beheben, schlagen diese alle fehl. Obwohl wir window.sessionStorage.getItem = jest.fn(); , sagt ein nachfolgendes expect(window.sesssionStorage.getItem).toHaveBeenCalled() nicht, dass es sich nicht um eine Scheinfunktion handelt.

Ich stimme zwar zu, dass das Hinzufügen einer Funktion eine geringfügige Versionsänderung und keine bahnbrechende Änderung ist, aber wenn es ein Standardbestandteil von Browsern ist und die neue Implementierung anscheinend nicht überschrieben oder verspottet werden kann, ist dies _ist_ eine bahnbrechende Änderung .

Die einzige Lösung, die ich für mein Problem gefunden habe, besteht darin, jsdom zu meiner package.json hinzuzufügen und eine Version von 11.11.0 anzugeben. Dies ist nicht ideal und wird später zusätzliche Arbeit verursachen, wenn wir Pakete erneut aktualisieren, aber zumindest für den Moment werden wir dadurch entsperrt.

Wenn Sie Code haben, z. B. Mocking-Code, der in Browsern funktioniert, aber nicht in jsdom, reichen Sie ein neues Problem gemäß der Problemvorlage ein und wir können es untersuchen. Meines Wissens ist localStorage in jsdom genauso verspottbar wie in Browsern.

Ich schlage vor, nicht verschiedene Versionen auf Ihrem Build-Server auszuführen, während Ihre Entwickler ausgeführt werden.

"Ich schlage vor, auf Ihrem Build-Server keine anderen Versionen auszuführen, während Ihre Entwickler laufen."

Das klingt zwar theoretisch gut, es sei denn, jeder Paketentwickler hört bei der Angabe von Abhängigkeitsversionen auf, "^" zu verwenden, oder wir übertragen die Tausenden von Ordnern in unserem Ordner node_modules, aber das wird nie passieren. Von einem Entwicklercomputer zum nächsten wird es wahrscheinlich leichte Unterschiede in einigen der Abhängigkeiten geben, die ein oder zwei Ebenen tiefer liegen. Ich kann nur die genauen Versionen der Pakete angeben, die direkte Abhängigkeiten von unserer Anwendung sind.

https://docs.npmjs.com/files/package-locks

Stimme @mrobrian bezüglich "^" voll und

@domenic Workaround mit packge-lock.json und yarn.lock ist konstruktionsbedingt defekt. Vielleicht hilft es bei Versionen, aber dann entstehen andere Probleme bei der Codeüberprüfung und beim Zusammenführen und oft müssen Sie diese Datei durch Löschen neu erstellen. Es ist in Ordnung, wenn Abhängigkeiten selten aktualisiert werden, aber wir aktualisieren sehr oft.

Deshalb unsere .npmrc :

save-exact = true
package-lock = false

es hat mir geholfen, diese neuen Zeilen zu package.json hinzuzufügen:

"jest": {
    "verbose": true,
    "testURL": "http://localhost/"
  },

Wenn Sie jsdom verwenden, stellen Sie sicher, dass Sie die URL einschließen

const dom = neues JSDOM(``, {
URL: "https://example.org/",
});

Möchten die scherzhaften Entwickler kommentieren, warum "testEnvironment": "node" jetzt für CLI/Knoten-Projekte erforderlich ist (um den localStorage Fehler zu vermeiden), obwohl dies zuvor nicht erforderlich war? Ist es ein Fehler?

Wenn dies irgendwie beabsichtigt ist, braucht es wirklich eine bessere Fehlermeldung! Ich erhalte diesen Fehler in beiden meiner Projekte, die Jest verwenden - zwei einfache Nicht-Browser-Projekte mit wenigen Abhängigkeiten. Sie verwenden sicherlich nicht jsdom/localStorage.

Dies ist nicht der richtige Ort, um Jest-Entwicklern Fragen zu stellen - jsdom ist ein separates Projekt. Die obigen Kommentare enthalten jedoch bereits die Antworten auf Ihre Fragen.

Paket.json

   ...
  "jest": {
    "testEnvironment": "node",
    "roots": [
      "test/javascript"
    ]
  },

Für mich geht das.

@p8ul hatte Recht, vergiss nicht " http://localhost " anzugeben (Standard-URL seit Jest 23.5.0, siehe #6792):

const dom = new JSDOM(``, {
url: "http://localhost",
});

Das ganze funktioniert bei mir.
Nicht einmal hinzufügen müssen:

"testEnvironment": "node"

Jest 23.5.0 enthält jetzt einen Fix dafür, sodass die Workarounds nicht mehr benötigt werden sollten:

https://github.com/facebook/jest/issues/6766#issuecomment -412516712

Ähnlich wie @mica16 https://github.com/jsdom/jsdom/issues/2304#issuecomment -412663502

const dom = new JSDOM(``, {
  url: "http://localhost",
});

War die einzige Änderung, die wir vornehmen mussten, um diesen Fehler zu vermeiden.

Wir verwenden Mokka/Enzym. Kein Scherz in unserer Testsuite enthalten.

Das Setzen von --env node auf der Kommandozeile funktioniert auch.

@gokulkrishh Ich habe es auf http://localhost/ aber jede gültige URL scheint zu funktionieren.

"location.href" wäre dann schön. :)

@domenic Ich empfehle, Ihren Kommentar oben zu aktualisieren, um zu sagen, dass die Jest-Betreuer diesen Fehler in Version 23.5.0 behoben haben: https://github.com/facebook/jest/issues/6766#issuecomment -412516712

Ich bestätige, dass das Setzen von testURL für jest-config auf http://localhost funktioniert.

Schlüssel in Konfigurationsdatei hinzufügen und erneut versuchen "jest": { "testURL": " http://localhost%26quot%3B/ },
IP-Port anstelle von localhost verwenden
Dies könnte das Problem lösen

Ich bin auf das Problem gestoßen, nachdem ich beim Ausführen von npm audit einige Sicherheitsprobleme entdeckt hatte. Nachdem ich sie mit npm audit fix behoben hatte, stieß ich auf dieses Problem.

Da dies in Jest seit einiger Zeit behoben wurde, versuchen wir es zu schließen und zu sehen, ob wir viele Duplikate haben oder ob sich die Dinge genug beruhigt haben.

"scherz": {
"ausführlich": wahr,
"testURL": " http://localhost/ "
}
Fügen Sie dieses Code-Snippet in der Datei package.json hinzu.
Bei mir hat es funktioniert.

Sie können dies auch zum betroffenen Test hinzufügen, wenn jsdom dort nicht benötigt wird

``` Javascript 1.6
/**

• @jest-environment node
  */

it('mein Test', () => {
erwarten(2 + 2).toBe(4);
});
```

Ich habe beide Möglichkeiten getestet:

1) Fügen Sie dies am Anfang einer Testdatei hinzu:

/**
 * @jest-environment node
 */

2) Fügen Sie diese Zeilengruppe zu package.json hinzu:

"jest": {
    "testURL": "http://localhost/"
  }

Beide Optionen haben funktioniert.

Ich ließ es funktionieren, indem ich die Datei package.json hinzufügte:

"jest": {
    "verbose": true,
    "testURL": "http://localhost/"
  }

@gokulkrishh Ich habe es auf http://localhost/ gesetzt, aber jede gültige URL scheint zu funktionieren.

Ich bin ein Neuling. Kannst du mir genau sagen, wo in der Jest.config.js ich die testURL festlege?

@haiphu Überall in jest.config.js wie unten

{
"testURL": "http://localhost/"

// Your other config
}

Ich habe das Folgende zu meinem package.json hinzugefügt und es funktioniert jetzt gut :)

  "jest": {
    "testURL": "http://localhost/"
  },

Ich bin mir nicht sicher warum, aber mein Fehler wurde durch verschiedene Typoskriptversionen verursacht.

Ich habe ein Mono-Repo-Setup mit Garn-Workspaces + lerna. Alle Pakete hatten typescript@^3.3.3 in ihrer package.json. Ich habe ein neues Paket hinzugefügt und das neueste typescript@^3.5.3 installiert. Als ich Tests in den vorhandenen Paketen durchführte, erhielt ich diesen Fehler.

Wenn ich alle Pakete in dieselbe Version verschiebe - entweder typescript@^3.3.3 oder typescript@^3.5.3 , verschwindet der Fehler. Ich musste nicht mit den testURL .

@tylerreece22 @gokulkrishh Hat für mich

Für diejenigen, die sich fragen, was die Konfigurationsdirektive testURL jest tut, siehe https://jestjs.io/docs/en/configuration#testurl -string

Für diejenigen, die die Optionen auf jsdom direkt einstellen (zum Beispiel bei der Verwendung von Mocha). Fügen Sie dies in Ihre setup.js ein:

let jsdom = require('jsdom-global')(
    undefined,
    {
        url: "http://localhost"
    }
);

Merkwürdiger .. Ich habe keine jsdom verwendet werden .. Ich bin mit Spaß für einige Knoten nur Pakete testen noch diese Fehler gestartet CI blockieren , wenn jest Versionen spätestens innerhalb von Upgrade ^11 Bereich .. Ich bin sicher , dass andere Leute sehen ähnliche Probleme. Keine der bisher empfohlenen Änderungen scheint das Problem zu beheben

Wenn Sie jsdom nicht verwenden, sollten Sie die jest-Konfigurationseigenschaft testEnvironment auf node . (Sie müssen testURL nicht berühren)
https://jestjs.io/docs/en/configuration#testenvironment -string

Für alle, die nach der tatsächlichen Lösung suchen, ist es new JSDOM('', { url: 'https://localhost' })

Versuchen Sie dies in Ihrer package.json-Datei zu verwenden

"scherz": {
"ausführlich": wahr,
"testURL": " http://localhost/ "
}

Warum das Festlegen der URL bei mir nicht funktioniert ... ich verwende Reaktiv-native .. gibt es noch etwas, das ich vermisse?

Warum das Festlegen der URL bei mir nicht funktioniert ... ich verwende Reaktiv-native .. gibt es noch etwas, das ich vermisse?

Wir hatten das gleiche Problem. In unserer Bewerbung hatten wir diesen Code

const { JSDOM } = require('jsdom');
const jsdom = new JSDOM('<!doctype html><html><body></body></html>');

Es stellte sich heraus, dass wir die URL zum JSDOM-Konstruktor hinzufügen mussten

const { JSDOM } = require('jsdom');
const jsdom = new JSDOM('<!doctype html><html><body></body></html>', {
  url: 'http://localhost/',
});

Das hat das Problem behoben.

Warum das Festlegen der URL bei mir nicht funktioniert ... ich verwende Reaktiv-native .. gibt es noch etwas, das ich vermisse?

Wir hatten das gleiche Problem. In unserer Bewerbung hatten wir diesen Code

const { JSDOM } = require('jsdom');
const jsdom = new JSDOM('<!doctype html><html><body></body></html>');

Es stellte sich heraus, dass wir die URL zum JSDOM-Konstruktor hinzufügen mussten

const { JSDOM } = require('jsdom');
const jsdom = new JSDOM('<!doctype html><html><body></body></html>', {
  url: 'http://localhost/',
});

Das hat das Problem behoben.

Das hat bei mir funktioniert, vielen Dank! Das Einfügen der URL in die jest-Konfiguration scheint mit Reactive-Native nicht zu funktionieren. Das Einfügen der URL in den jsdom-Konstruktor hat den Zweck erfüllt.

Update von 22 auf 26 Problem behoben.

Verwenden Sie einfach die neueste Version von jest. derzeit verwende ich 26.5.0 im Jahr 2020 und mein Problem ist gelöst

Versuchen Sie dies in Ihrer package.json-Datei zu verwenden

"scherz": {
"ausführlich": wahr,
"testURL": " http://localhost/ "
}

Dass testURL die Standard-URL ist, was bedeutet, dass es das Problem nicht löst, zumindest nicht bei Jest 26.x . Ich musste tun, was @zuccha getan hat, um es zu