Apollo-link: A importação observável zen quebra as consultas no cliente Apollo quando transpilada

Estou com o mesmo problema, mas com erro de diferença.

Meu código está aqui.

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)

Eu tentei este trabalho arround e eu obtive o mesmo erro com o de @stevestreza .

`` `js
import 'isomorphic-fetch'
import * as apolloLink de 'apollo-link'
import Observable from 'zen-observable'
apolloLink.Observable = Observável
`` ``

@stevestreza @mizchi quais versões do apollo-client e apollo-link você está usando?

O mesmo problema aqui, com [email protected] em um projeto webpack, corrigido removendo o * as na instrução de importação, como @stevestreza apontou.

O mesmo problema aqui.

O mesmo aqui, e gostaria de acrescentar que o problema não está dentro do Webpack, conforme escrito no SO, mas no Apollo e / ou TypeScript.

O motivo pelo qual sei é que estou usando o Rollup para criar um bundle em vez do Webpack.

Acho que é um bug do TypeScript + Rollup, mas estou surpreso que não esteja se manifestando em nossas próprias compilações de Rollup. Alguém aqui poderia abrir uma solicitação pull fazendo a alteração sugerida acima?

O mesmo problema aqui com Rollup. Eu também não estou usando o Typescript.

Parece que o TS está todo confuso. Tentei construir o módulo para corrigir os erros, mas estava obtendo erros de TS.

Olá, desculpe minha pergunta, mas alguém tem um hotfix enquanto isso está sendo resolvido? alguma ideia de qual era a última versão estável?

em minhas investigações até agora, acho que esse problema ocorre apenas fora do criar-reagir-app. portanto, há alguma suposição implícita dentro do aplicativo criar-reagir que não está sendo documentado que está causando o problema _super.call is not a function .

Mesmo problema aqui, apenas segui o doc em um projeto totalmente novo e recebi este erro. Não consigo continuar com o Apollo.

apenas vinculando meu outro problema aqui: https://github.com/apollographql/apollo-client/issues/2785#issuecomment -354169337 onde há uma correção proposta (eu não testei)

não tenho certeza se isso está relacionado, mas ...

estou usando o rollup para criar um pacote para um aplicativo de reação muito simples. tudo está funcionando bem até eu tentar introduzir apollo-client na mistura.

seguindo a documentação aqui: https://www.apollographql.com/docs/react/basics/setup.html#installation

depois de tentar construir o projeto com rollup, recebo o seguinte erro durante a construção:

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: }

ive tentei alterar a importação em node_modules/apollo-link/lib/link.js para import Observable from 'zen-observable'; conforme sugerido no problema relacionado acima, mas isso não parece corrigir o problema.

Estou enfrentando um problema com o observável zen que é bem diferente. por favor dê uma olhada em
https://github.com/apollographql/apollo-link/issues/389
e sugerir se estou fazendo algo errado.

Estou tão lutando que não tenho escolha a não ser usar o seguinte hack para contornar este problema ...

webpack.config.js

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

Eu realmente gostaria de poder obter alguma ajuda aqui para poder remover este hack ...

PS Eu não uso TypeScript, apenas babel. Não tenho certeza se esta é a razão pela qual está quebrado para mim

Recebo o mesmo erro sem datilografar e posso garantir que fazer a alteração

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

corrige o problema

droga @kinyat, eu não fazia ideia que você poderia fazer isso com o webpack. TIL !!! obrigada!!!

O mesmo problema em um aplicativo Hello World básico com react-apollo e parcel-bundler . Alguma solução legal ?

@alapini Acho que uma das soluções "legais" é a Apollo fornecer ao usuário não-digitado (isto é, Babel) uma versão ES5 do compilador ts.

Estou usando o apollo para meu plugin vuex-orm-apollo e alterar arquivos dentro do node_modules não é uma opção viável para mim. Uma correção de bug em breve seria muito bom! :)

com a versão mais recente do texto datilografado, as importações podem ser expressas na sintaxe normal dos módulos es, então talvez se todos nós esperarmos que o Apollo atualize a versão datilografada, isso funcionará imediatamente para nós, não usuários de TS.

Acho que estou tendo alguns dos mesmos problemas listados aqui. Primeira vez usando o Apollo, então não tenho 100% de certeza se estou conectando as coisas corretamente. Estou usando rollup sem texto datilografado com 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

Para aqueles que usam parcel.js, este PR parece corrigir temporariamente o problema: https://github.com/parcel-bundler/parcel/pull/530

Não mergulhei muito neste problema, mas parece que o cerne da questão, como @fathyb observa aqui , é:

O comportamento atual do Babel é totalmente correto e respeita as especificações ES6. Importar uma exportação padrão com um caractere curinga é ilegal, portanto, os erros aqui são legítimos.

No entanto, as pessoas ( # 418 ) e as bibliotecas (antd, @ blueprintjs / core, etc.) ainda contam com isso. A ideia é ser mais tolerante relaxando a especificação de namespaces exóticos.

Portanto, parece que a solução alternativa postada por @stevestreza (removendo * as ) é uma correção legítima para o apollo-link, não?

Fwiw, eu estava recebendo o erro _apolloLink.Observable is not a constructor , e ele desaparece se eu usar o PR parcel.js mencionado acima (ou reverter para parcel.js 1.2.1 conforme observado em apollo-client / issues / 2785 )

Também estou tendo esse problema ao usar o Rollup em um projeto Vuejs.

obrigado por compartilhar @ tadas412

O PR acima foi publicado em 1.2.0. Avise-me se ainda não tiver resolvido!

ainda obtendo um erro com 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

isso parece ser rastreado aqui apollographql / apollo-client / issues / 2785 também

Para mim, funciona com 1.2.0.

@littletower Isso pode parecer estúpido, mas tem certeza de que está usando o 1.2.0? Talvez deletar o diretório node_modules e reinstalar os pacotes? Só perguntando :)

@phortx sim, já fiz isso :(
Devo acrescentar que estou usando assinaturas, não sei se isso muda alguma coisa

@littletower Isso é estranho. Eu estava recebendo o mesmo erro com 1.1.0 e 1.2.0 parecia resolver isso. apollo-client tem uma dependência de apollo-link , então pode ser que sua dependência não tenha sido atualizada. Você pode criar um repo de reprodução?

A mudança definitivamente corrigiu o problema real de nível de código, mas parece que yarn está causando um conflito.

• Quando eu uso npm install para instalar as dependências, ele carrega apollo-link 1.2.0 sem nenhuma alteração de apollo-client . Isso funciona muito bem e o problema relatado não acontece mais. (Você deve instalar manualmente graphql-tag e remover as chaves na importação em src/client/index.js para verificar isso)
• Quando eu uso yarn install , ele instala a versão apollo-link 1.0.0. Quando eu yarn add apollo-link para instalar explicitamente 1.2.0, a versão em node_modules/apollo-link torna-se 1.2.0, mas outra versão de apollo-link 1.0.0 é instalada em node_modules/apollo-client/node_modules/apollo-link .

Não tenho conhecimento neste ponto sobre como o yarn funciona para consertar isso (eu esperava que ele tivesse instalado apollo-link 1.2.0, não 1.0.0). Eu acho que a correção "certa" é exigir apollo-link 1.2.0 no package.json por apollo-client . Vou deixar uma nota em apollographql / apollo-client # 2785.

De qualquer forma, isso parece totalmente corrigido aqui!

@evans Eu criei um

Estou recebendo o mesmo erro em um projeto do Polymer 3 e apollo-boost :

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

causas

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

@heruan Você encontrou alguma solução? Eu estou enfrentando o mesmo problema.