Apollo-link: zen-observable import unterbricht Abfragen im apollo-client beim Transpilieren

Erstellt am 15. Nov. 2017  ·  34Kommentare  ·  Quelle: apollographql/apollo-link

Vielen Dank, dass Sie ein Problem bei Apollo Link eingereicht haben! Bitte stellen Sie sicher, dass Sie die folgenden Informationen angeben, um sicherzustellen, dass Ihr Problem bearbeitet werden kann. Wenn Sie eine Feature-Anfrage einreichen, müssen Sie die unten stehende Gliederung nicht befolgen, aber bitte fügen Sie im Titel "Feature-Idee" hinzu und fügen Sie ein konkretes Beispiel hinzu, in dem diese Funktion nützlich wäre.

Hi!

Ich arbeite daran, ein neues Projekt mit Apollo Client, Apollo Link, Babel und Webpack einzurichten. Ich verwende eine ziemlich einfache Projektvorlage, um sie mit den dokumentierten Vorschlägen in Apollo Client einzurichten. Wenn ich es ausführe und eine Abfrage sende, erhalte ich eine Laufzeitausnahme und Abfragen können nicht durchlaufen. Ich habe dies darauf zurückgeführt, wie das Paket zen-observable importiert wird.

Beabsichtigtes Ergebnis:

Apollo Client kann mit Apollo Link eine Abfrage mit folgendem Code durchführen:

import { ApolloClient } from "apollo-client"
import { HttpLink } from "apollo-link-http"
import { InMemoryCache } from "apollo-cache-inmemory"
import { gql } from "graphql-tag"

const graphqlClient = new ApolloClient({
        link: new HttpLink(),
        cache: new InMemoryCache(),
})
graphqlClient.query({ query: gql`query { counter { count } }` })
        .then(console.log)
        .catch(console.error)

Tatsächliches Ergebnis:

Apollo Client löst die folgende Ausnahme aus:

TypeError: _super.call is not a function
Stack trace:
ObservableQuery@webpack-internal:///16:56:21
QueryManager</QueryManager.prototype.watchQuery@webpack-internal:///94:404:16
QueryManager</QueryManager.prototype.query/resPromise<@webpack-internal:///94:431:20
QueryManager</QueryManager.prototype.query@webpack-internal:///94:429:26
ApolloClient</ApolloClient.prototype.query@webpack-internal:///93:102:16
@webpack-internal:///59:14:1
[59]<strong i="19">@http</strong>://host/assets/client.js:16:1
__webpack_require__<strong i="20">@http</strong>://host/assets/manifest.js:713:12
fn<strong i="21">@http</strong>://host/assets/manifest.js:118:20
[49]<strong i="22">@http</strong>://host/assets/client.js:7:18
__webpack_require__<strong i="23">@http</strong>://host/assets/manifest.js:713:12
webpackJsonpCallback<strong i="24">@http</strong>://host/assets/manifest.js:26:23
<strong i="25">@http</strong>://host/assets/client.js:1:1

Das ObservableQuery importiert das Observable aus dem Apollo Link Projekt, welches es aus dem zen-observable Paket importiert. Wenn es in JavaScript transpiliert wird, hat das apollo-link-Paket dies bei lib/index.js :

import * as Observable from 'zen-observable';
export { Observable };

Es scheint, dass dies beim Transpilieren und späteren Unterklassen dieses Observables zu einem seltsamen Fall führt, aber hier scheint die Methode call durch meine Untersuchung nicht mehr verfügbar zu sein.

So reproduzieren Sie das Problem:

Im Anhang ist ein Testprojekt, das das Problem demonstrieren soll. Ich gehe davon aus, dass Node.js v6 oder v8 mit Yarn installiert ist. Testprojekt

  1. Entpacken und in das Testprojekt cdieren
  2. yarn install
  3. yarn run start und öffnen Sie http://localhost :3000/
  4. Sie sollten den oben gezeigten Fehler in der Konsole sehen.

Sie können dies umgehen, indem Sie node_modules/apollo-link/lib/index.js:3 ändern von:

import * as Observable from 'zen-observable';

zu:

import Observable from 'zen-observable';

Das Problem ist, wenn Sie diese Änderung in der entsprechenden .ts-Datei vornehmen, führt dies zu einem Linting-Fehler, und ich bin mir nicht sicher, wie ich das am besten beheben kann.

Es gibt dieses Problem bei StackOverflow, das darauf hindeutet, dass andere Personen dieses Problem haben.

Vielen Dank für Ihre Zeit, für das Betrachten meines Fehlerberichts und für die großartige Arbeit an Apollo!

bug

Hilfreichster Kommentar

Ich habe so Probleme, dass ich keine andere Wahl habe, als den folgenden Hack zu verwenden, um dieses Problem zu umgehen ...

webpack.config.js

      {
        test: /node_modules\/apollo-link.*?\/lib\/.*?.js/,
        loader: 'string-replace-loader',
        options: {
          search: 'exports.Observable = Observable',
          replace: 'exports.Observable = Observable.default'
        }
      },

Ich wünschte wirklich, ich könnte hier Hilfe bekommen, damit ich diesen Hack entfernen kann ...

PS Ich benutze kein TypeScript sondern nur Babel. Ich bin mir nicht sicher, ob dies der Grund ist, warum es mir kaputt geht

Alle 34 Kommentare

Ich habe das gleiche Problem, aber mit Unterschiedsfehler.

Mein Code ist hier.

import 'isomorphic-fetch'
import { ApolloLink } from 'apollo-link'
import { ApolloClient } from 'apollo-client'
import { HttpLink } from 'apollo-link-http'
import { InMemoryCache } from 'apollo-cache-inmemory'

export default new ApolloClient({
  link: new HttpLink({ uri: 'http://localhost:5000/api/graphql' }),
  cache: new InMemoryCache()
})
Uncaught (in promise) TypeError: _apolloLink.Observable is not a constructor
    at HttpLink.eval [as request] (httpLink.js:98)
    at eval (link.js:60)
    at ApolloLink.eval [as request] (ApolloClient.js:30)
    at ApolloLink.eval [as request] (link.js:59)
    at execute (link.js:94)
    at eval (QueryManager.js:134)
    at new Promise (<anonymous>)
    at QueryManager.mutate (QueryManager.js:129)
    at ApolloClient.mutate (ApolloClient.js:109)
    at Header.componentDidMount (index.js:53)

Ich habe diese Arbeit in der Nähe ausprobiert und habe den gleichen Fehler mit @stevestreza bekommen .

```js
import 'isomorphic-fetch'
* als apolloLink aus 'apollo-link' importieren
Observable von 'zen-observable' importieren
apolloLink.Observable = Observable
````

@stevestreza @mizchi welche Versionen von apollo-client und apollo-link verwenden Sie?

Das gleiche Problem hier, mit [email protected] in einem Webpack-Projekt, das durch Entfernen von * as in der Importanweisung behoben wurde , wie

Gleiches Problem hier.

Das gleiche hier, und ich möchte hinzufügen, dass das Problem nicht in Webpack liegt, wie auf SO geschrieben, sondern in Apollo und / oder TypeScript.

Ich weiß, dass ich Rollup verwende, um ein Bundle anstelle von Webpack zu erstellen.

Ich denke, dies ist ein TypeScript + Rollup-Fehler, aber ich bin überrascht, dass er sich nicht in unseren eigenen Rollup-Builds manifestiert. Wäre hier jemand bereit, eine Pull-Anfrage zu öffnen, die die oben vorgeschlagene Änderung vornimmt?

Gleiches Problem hier mit Rollup. Ich verwende auch kein Typescript.

Sieht so aus, als ob TS alles vermasselt ist. Ich habe versucht, das Modul zu bauen, um die Fehler zu beheben, bekam aber TS-Fehler.

Hallo, entschuldigen Sie meine Frage, aber hat jemand einen Hotfix, während das Problem gelöst wird? Hast du eine Ahnung, was die letzte stabile Version war?

In meinen bisherigen Untersuchungen denke ich, dass dieses Problem nur außerhalb von create-react-app auftritt. Es gibt also eine implizite Annahme in create-react-app, die nicht dokumentiert ist und die dieses _super.call is not a function Problem verursacht.

Das gleiche Problem hier, ich bin gerade dem Dokument bei einem brandneuen Projekt gefolgt und habe diesen Fehler erhalten. Ich kann mit Apollo nicht weitermachen.

Verlinke einfach mein anderes Problem hier: https://github.com/apollographql/apollo-client/issues/2785#issuecomment -354169337 wo es eine vorgeschlagene Lösung gibt (ich habe nicht getestet)

bin mir nicht sicher ob das zusammenhängt aber...

Ich verwende Rollup, um ein Bundle für eine sehr einfache Reaktions-App zu erstellen. alles funktioniert gut, bis ich versuche, apollo-client in den Mix einzuführen.

Folgen Sie der Dokumentation hier: https://www.apollographql.com/docs/react/basics/setup.html#installation

Nachdem ich versucht habe, das Projekt mit Rollup zu erstellen, erhalte ich während des Builds die folgende Fehlermeldung:

of is not exported by node_modules/zen-observable/index.js
47:         return new ApolloLink(function (operation, forward) {
48:             return (firstLink.request(operation, function (op) {
49:                 return nextLink.request(op, forward) || Observable.of();
                                                                       ^
50:             }) || Observable.of());
51:         });
node_modules/apollo-link/lib/link.js
of is not exported by node_modules/zen-observable/index.js
48:             return (firstLink.request(operation, function (op) {
49:                 return nextLink.request(op, forward) || Observable.of();
50:             }) || Observable.of());
                                 ^
51:         });
52:     }
node_modules/apollo-link/lib/link.js
of is not exported by node_modules/zen-observable/index.js
74: export { ApolloLink };
75: export function execute(link, operation) {
76:     return (link.request(createOperation(operation.context, transformOperation(validateOperation(operation)))) || Observable.of());
                                                                                                                                 ^
77: }

Ich habe versucht, den Import in node_modules/apollo-link/lib/link.js in import Observable from 'zen-observable'; ändern, wie im obigen Problem vorgeschlagen, aber es scheint das Problem nicht zu beheben.

Ich stehe vor einem Problem mit zen-observable, das ganz anders ist. bitte schau mal rein
https://github.com/apollographql/apollo-link/issues/389
und schlage vor, wenn ich etwas falsch mache.

Ich habe so Probleme, dass ich keine andere Wahl habe, als den folgenden Hack zu verwenden, um dieses Problem zu umgehen ...

webpack.config.js

      {
        test: /node_modules\/apollo-link.*?\/lib\/.*?.js/,
        loader: 'string-replace-loader',
        options: {
          search: 'exports.Observable = Observable',
          replace: 'exports.Observable = Observable.default'
        }
      },

Ich wünschte wirklich, ich könnte hier Hilfe bekommen, damit ich diesen Hack entfernen kann ...

PS Ich benutze kein TypeScript sondern nur Babel. Ich bin mir nicht sicher, ob dies der Grund ist, warum es mir kaputt geht

Ich erhalte den gleichen Fehler ohne Typoskript und kann bestätigen, dass ich die Änderung vorgenommen habe

import * as Observable from 'zen-observable';
zu:
import Observable from 'zen-observable';

behebt das Problem

Verdammt @kinyat Ich hatte keine Ahnung, dass du das mit Webpack machen kannst. BIS!!! Danke schön!!!

Gleiches Problem in einer einfachen Hello World-App mit react-apollo und parcel-bundler . Irgendeine rechtliche Lösung?

@alapini Ich denke, eine der "legalen" Lösungen besteht darin, dass Apollo einem Nicht-Typoskript-Benutzer (dh Babel) eine ES5-Version vom ts-Complier zur Verfügung stellt.

Ich verwende apollo für mein vuex-orm-apollo-Plugin und das Ändern von Dateien innerhalb von node_modules ist für mich keine praktikable Option. Ein baldiger Bugfix wäre wirklich schön! :)

Mit der neuesten Version von Typescript können die Importe in der normalen Syntax von es modulen ausgedrückt werden. Wenn wir also alle darauf warten, dass Apollo die Typescript-Version aktualisiert, wird dies für uns Nicht-TS-Benutzer sofort funktionieren.

Ich glaube, ich stoße auf einige der gleichen Probleme, die hier aufgelistet sind. Ich benutze apollo zum ersten Mal, daher bin ich nicht 100% sicher, ob ich die Dinge richtig anschließe. Ich verwende Rollup ohne Typoskript mit Inferno.

The 'this' keyword is equivalent to 'undefined' at the top level of an ES module, and has been rewritten
The 'this' keyword is equivalent to 'undefined' at the top level of an ES module, and has been rewritten
The 'this' keyword is equivalent to 'undefined' at the top level of an ES module, and has been rewritten

'of' is not exported by 'node_modules/zen-observable/index.js'
'of' is not exported by 'node_modules/zen-observable/index.js'
'of' is not exported by 'node_modules/zen-observable/index.js'

(node:37350) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): Error: 'print' is not exported by node_modules/graphql/language/printer.js
(node:37350) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code

Für diejenigen, die packet.js verwenden, scheint dieser PR das Problem vorübergehend zu beheben: https://github.com/parcel-bundler/parcel/pull/530

Ich habe mich nicht allzu tief mit diesem Problem befasst, aber es scheint, dass der Kern des Problems, wie @fathyb hier feststellt, ist:

Das aktuelle Verhalten von Babel ist völlig korrekt und respektiert die ES6-Spezifikation. Das Importieren eines Standardexports mit einem Platzhalter ist illegal, daher sind die Fehler hier legitim.

Die Leute ( #418 ) und Bibliotheken (antd, @blueprintjs/core usw.) verlassen sich jedoch immer noch darauf. Die Idee ist, toleranter zu sein, indem die Spezifikation für exotische Namespaces gelockert wird.

Es scheint also, dass die von @stevestreza gepostete * as ) eine legitime Lösung für apollo-link ist, nicht wahr ?

Fwiw, ich habe den Fehler _apolloLink.Observable is not a constructor , und er verschwindet, wenn ich den oben genannten package.js PR verwende (oder wie in apollo-client/issues/2785 angegeben zu packet.js 1.2.1 zurückkehre).

Ich habe dieses Problem auch bei der Verwendung von Rollup in einem Vuejs-Projekt.

danke fürs teilen @tadas412

Die obige PR wurde in 1.2.0 veröffentlicht. Melde mich wenn es immer noch nicht gelöst ist!

bekomme immer noch einen Fehler mit 1.2.0 😢

TypeError: _super.call is not a function
    at new ObservableQuery
    at QueryManager.watchQuery 
    at eval 
    at new Promise 
    at QueryManager.query 
    at ApolloClient.query
    at VueComponent.created

dies scheint auch hier apollographql/apollo-client/issues/2785 verfolgt zu werden

Bei mir funktioniert es mit 1.2.0.

@littletower Das mag dumm klingen, aber bist du sicher, dass du 1.2.0 verwendest? Vielleicht das node_modules-Verzeichnis löschen und die Pakete neu installieren? Nur Fragen :)

@phortx ja das hab ich schon gemacht :(
Ich könnte hinzufügen, dass ich Abonnements verwende, weiß nicht, ob das etwas ändert

@littletower Das ist seltsam. Ich bekam den gleichen Fehler mit 1.1.0 und 1.2.0 schien ihn zu beheben. apollo-client hat eine Abhängigkeit von apollo-link , daher kann es sein, dass die Abhängigkeit nicht aktualisiert wurde. Können Sie ein Reproduktionsrepo erstellen?

Die Änderung hat das eigentliche Problem auf Codeebene definitiv behoben, aber es sieht so aus, als würde yarn einen Konflikt verursachen.

  • Wenn ich npm install , um die Abhängigkeiten zu installieren, wird apollo-link 1.2.0 ohne Änderung von apollo-client geladen. Das funktioniert super und das gemeldete Problem tritt nicht mehr auf. (Sie müssen graphql-tag manuell installieren und die geschweiften Klammern im Import in src/client/index.js entfernen, um dies zu überprüfen)
  • Wenn ich yarn install , wird Version apollo-link 1.0.0 installiert. Wenn ich yarn add apollo-link 1.2.0 explizit installiere, wird die Version in node_modules/apollo-link 1.2.0, aber eine andere Version von apollo-link 1.0.0 wird unter node_modules/apollo-client/node_modules/apollo-link installiert.

Ich bin an dieser Stelle über mein Wissen hinaus, wie Garn funktioniert, um dies zu beheben (ich würde erwarten, dass apollo-link 1.2.0 installiert ist, nicht 1.0.0). Ich würde vermuten, dass die "richtige" Lösung darin besteht, apollo-link 1.2.0 in der package.json für apollo-client zu benötigen. Ich schreibe eine Notiz in apollographql/apollo-client#2785.

Wie auch immer, dies scheint hier vollständig behoben zu sein!

@evans Ich habe ein Repo zur Reproduktion erstellt und

Ich erhalte den gleichen Fehler in einem Polymer 3-Projekt und apollo-boost :

import { HttpLink } from 'apollo-link-http';

Ursachen

Uncaught SyntaxError: The requested module '../../zen-observable/index.js'
                      does not provide an export named 'default'

@heruan Hast du eine Lösung gefunden? Ich stehe vor dem gleichen Problem.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen