Gatsby: A compilação falha depois com "token inesperado" em `async-requer` após a atualização para 2.0.84

Estou tendo um erro semelhante depois de atualizar de 2.0.62 para 2.0.91 .

No meu caso, gatsby develop funciona bem, mas gatsby build erros na página template.js (se eu incluí-la) ou 404.js (se eu remover o createPages snippet de gatsby-node ):

error Generating JavaScript bundles failed

Error: ./.cache/async-requires.js 8:11
  Module parse failed: Unexpected token (8:11)
  You may need an appropriate loader to handle this file type.
  | exports.components = {
  |   "component---src-templates-template-js": function componentSrcTemplatesTemplateJs() {
  >     return import("/Users/michael/Sites/projects/gatsby-starter/src/templates/template.js"
  |     /* webpackChunkName: "component---src-templates-template-js" */  |     );
   @ ./.cache/production-app.js 18:0-45 21:23-36 26:23-36

ou

error Generating JavaScript bundles failed

Error: ./.cache/async-requires.js 8:11
  Module parse failed: Unexpected token (8:11)
  You may need an appropriate loader to handle this file type.
  | exports.components = {
  |   "component---src-pages-404-js": function componentSrcPages404Js()   {
  >     return import("/Users/michael/Sites/projects/gatsby-starter/src/pages/404.js"
  |     /* webpackChunkName: "component---src-pages-404-js" */
  |     );
   @ ./.cache/production-app.js 18:0-45 21:23-36 26:23-36

Tudo funcionou bem antes de atualizar gatsby . 🤷‍♂️

@dlindahl @ooloth

Você pode criar um link para reproduções mínimas disso?

Estou recebendo o mesmo erro ao usar o Gatsby v 2.0.55, em que package-lock.json está desabilitado em .npmrc. O site é construído diariamente a partir de um espaço de trabalho limpo. Um dia funcionou, no outro não. Estou supondo que o erro está relacionado a alguma dependência temporária que mudou.

o mesmo problema quando atualizo gatsby de v2.0.91 para v2.0.93 ( v2.0.92 ) não existe

Olá, entrando na minha cabeça para dizer que também estou enfrentando esse problema, mas estou lutando para construir uma reprodução mínima para ele.

Executando um npm update no meu repositório faz com que a compilação falhe, mas não para o meu site pessoal .

Vou continuar a vasculhar até encontrar o que está causando isso ou outra pessoa descobrir. Se eu conseguir isolá-lo de forma limpa, postarei de volta aqui.

Obrigado!

O mesmo aqui!
Digitei npm update -g npm para obter a versão npm 6.7.0 e tenho o gatsby 2.0.98.

Versão offline do plugin gatsby -> 2.0.21

Repositório com este problema: pronto .

Você também pode listar as dependências instaladas com npm ls e executar node --version ?

A divisão em duas também pode ser útil aqui. Vou testar o repo em alguns minutos.

Ok mesmo erro aqui. Vou dividir isso ao meio.

Parece que isso acontece em todas as versões, então é um plugin ou outra dependência provavelmente.
Irá testar mais.

Acho que encontrei a causa. Vou fornecer um patch e PR.

@omrllm (um patch para gatsby 2.0.60)

patch-package
--- a/node_modules/gatsby/dist/internal-plugins/query-runner/pages-writer.js
+++ b/node_modules/gatsby/dist/internal-plugins/query-runner/pages-writer.js
@@ -86,9 +86,9 @@ const preferDefault = m => m && m.default || m
     let asyncRequires = `// prefer default export if available
 const preferDefault = m => m && m.default || m
 \n`;
-    asyncRequires += `exports.components = {\n${components.map(c => `  "${c.componentChunkName}": () => import("${(0, _path.joinPath)(c.component)}" /* webpackChunkName: "${c.componentChunkName}" */)`).join(`,\n`)}
+    asyncRequires += `exports.components = {\n${components.map(c => `  "${c.componentChunkName}": () => require("${(0, _path.joinPath)(c.component)}" /* webpackChunkName: "${c.componentChunkName}" */)`).join(`,\n`)}
 }\n\n`;
-    asyncRequires += `exports.data = () => import("${(0, _path.joinPath)(program.directory, `.cache`, `data.json`)}")\n\n`;
+    asyncRequires += `exports.data = () => require("${(0, _path.joinPath)(program.directory, `.cache`, `data.json`)}")\n\n`;

     const writeAndMove = (file, data) => {
       const destination = (0, _path.joinPath)(program.directory, `.cache`, file);

Alterando o import para require deve funcionar. Provavelmente há apenas um carregador faltando, mas por que usar import aqui de qualquer maneira quando o modo ESM apenas produz problemas e misturar exports com import nunca é uma boa ideia.

+ [email protected]
+ [email protected]
+ [email protected]
+ [email protected]
+ [email protected]
+ [email protected]
added 9 packages from 3 contributors, removed 4 packages, updated 92 packages and audited 43569 packages in 200.269s

diff 23.cache/ .cache/
Only in 23.cache/: .sonarlint
Common subdirectories: 23.cache/__tests__ and .cache/__tests__
Common subdirectories: 23.cache/caches and .cache/caches
Common subdirectories: 23.cache/commonjs and .cache/commonjs
diff 23.cache/data.json .cache/data.json
1c1
< {"pages":[{"componentChunkName":"component---src-pages-index-js","jsonName":"index","path":"/"},{"componentChunkName":"component---src-pages-404-js","jsonName":"404-html-516","path":"/404.html"},{"componentChunkName":"component---src-pages-404-js","jsonName":"404-22d","path":"/404/"},{"componentChunkName":"component---src-pages-about-js","jsonName":"about-f34","path":"/about/"},{"componentChunkName":"component---src-pages-contact-js","jsonName":"contact-26a","path":"/contact/"}],"dataPaths":{"404-22d":"657/path---404-22-d-bce-yc2HAWbdDECy3NCKIhFOCg1lY8","404-html-516":"84/path---404-html-516-62a-yc2HAWbdDECy3NCKIhFOCg1lY8","about-f34":"691/path---about-f-34-4c2-WV9OHhcgC975Z2f0az9WK5Dpl0Y","contact-26a":"662/path---contact-26-a-cd9-SNoLKPyPsqQ59X6yAuuT79ALOJc","index":"612/path---index-6a9-j0JKW3rrllGOOtWKwyNn0ujHMk"}}
\ No newline at end of file
---
> {"pages":[{"componentChunkName":"component---src-pages-index-js","jsonName":"index","path":"/"},{"componentChunkName":"component---src-pages-404-js","jsonName":"404-html-516","path":"/404.html"},{"componentChunkName":"component---src-pages-404-js","jsonName":"404-22d","path":"/404/"},{"componentChunkName":"component---src-pages-about-js","jsonName":"about-f34","path":"/about/"},{"componentChunkName":"component---src-pages-contact-js","jsonName":"contact-26a","path":"/contact/"}],"dataPaths":{"404-22d":"657/path---404-22-d-bce-yc2HAWbdDECy3NCKIhFOCg1lY8","404-html-516":"84/path---404-html-516-62a-yc2HAWbdDECy3NCKIhFOCg1lY8","about-f34":"691/path---about-f-34-4c2-WV9OHhcgC975Z2f0az9WK5Dpl0Y","contact-26a":"662/path---contact-26-a-cd9-SNoLKPyPsqQ59X6yAuuT79ALOJc","index":"770/path---index-6a9-dVi4vZoL0B52PVt3C79b9kQk"}}
\ No newline at end of file
diff 23.cache/default-html.js .cache/default-html.js
4,31c4,29
< export default class HTML extends React.Component {
<   render() {
<     return (
<       <html {...this.props.htmlAttributes}>
<         <head>
<           <meta charSet="utf-8" />
<           <meta httpEquiv="x-ua-compatible" content="ie=edge" />
<           <meta
<             name="viewport"
<             content="width=device-width, initial-scale=1, shrink-to-fit=no"
<           />
<           {this.props.headComponents}
<         </head>
<         <body {...this.props.bodyAttributes}>
<           {this.props.preBodyComponents}
<           <noscript key="noscript" id="gatsby-noscript">
<             This app works best with JavaScript enabled.
<           </noscript>
<           <div
<             key={`body`}
<             id="___gatsby"
<             dangerouslySetInnerHTML={{ __html: this.props.body }}
<           />
<           {this.props.postBodyComponents}
<         </body>
<       </html>
<     )
<   }
---
> export default function HTML(props) {
>   return (
>     <html {...props.htmlAttributes}>
>       <head>
>         <meta charSet="utf-8" />
>         <meta httpEquiv="x-ua-compatible" content="ie=edge" />
>         <meta
>           name="viewport"
>           content="width=device-width, initial-scale=1, shrink-to-fit=no"
>         />
>         {props.headComponents}
>       </head>
>       <body {...props.bodyAttributes}>
>         {props.preBodyComponents}
>         <noscript key="noscript" id="gatsby-noscript">
>           This app works best with JavaScript enabled.
>         </noscript>
>         <div
>           key={`body`}
>           id="___gatsby"
>           dangerouslySetInnerHTML={{ __html: props.body }}
>         />
>         {props.postBodyComponents}
>       </body>
>     </html>
>   )
Common subdirectories: 23.cache/fragments and .cache/fragments
Common subdirectories: 23.cache/json and .cache/json
diff 23.cache/navigation.js .cache/navigation.js
37c37
< const onPreRouteUpdate = location => {
---
> const onPreRouteUpdate = (location, prevLocation) => {
39c39
<     apiRunner(`onPreRouteUpdate`, { location })
---
>     apiRunner(`onPreRouteUpdate`, { location, prevLocation })
43c43
< const onRouteUpdate = location => {
---
> const onRouteUpdate = (location, prevLocation) => {
45c45
<     apiRunner(`onRouteUpdate`, { location })
---
>     apiRunner(`onRouteUpdate`, { location, prevLocation })
136c136
<     onPreRouteUpdate(props.location)
---
>     onPreRouteUpdate(props.location, null)
140c140
<     onRouteUpdate(this.props.location)
---
>     onRouteUpdate(this.props.location, null)
145c145
<       onRouteUpdate(this.props.location)
---
>       onRouteUpdate(this.props.location, prevProps.location)
151c151
<       onPreRouteUpdate(this.props.location)
---
>       onPreRouteUpdate(this.props.location, prevProps.location)
diff 23.cache/static-entry.js .cache/static-entry.js
55c55,59
<     <meta name="generator" content={`Gatsby ${gatsbyVersion}`} />,
---
>     <meta
>       name="generator"
>       content={`Gatsby ${gatsbyVersion}`}
>       key={`generator-${gatsbyVersion}`}
>     />,
354,360c358,366
<   const bodyScripts = scripts.filter(s => s.rel !== `prefetch`).map(s => {
<     const scriptPath = `${__PATH_PREFIX__}/${JSON.stringify(s.name).slice(
<       1,
<       -1
<     )}`
<     return <script key={scriptPath} src={scriptPath} async />
<   })
---
>   const bodyScripts = scripts
>     .filter(s => s.rel !== `prefetch`)
>     .map(s => {
>       const scriptPath = `${__PATH_PREFIX__}/${JSON.stringify(s.name).slice(
>         1,
>         -1
>       )}`
>       return <script key={scriptPath} src={scriptPath} async />
>     })

Difere após o atualizador e uma nova compilação execute @madelyneriksen

patch-package
--- a/node_modules/gatsby/dist/internal-plugins/query-runner/pages-writer.js
+++ b/node_modules/gatsby/dist/internal-plugins/query-runner/pages-writer.js
@@ -88,9 +88,9 @@ const preferDefault = m => m && m.default || m
     let asyncRequires = `// prefer default export if available
 const preferDefault = m => m && m.default || m
 \n`;
-    asyncRequires += `exports.components = {\n${components.map(c => `  "${c.componentChunkName}": () => import("${(0, _path.joinPath)(c.component)}" /* webpackChunkName: "${c.componentChunkName}" */)`).join(`,\n`)}
+    asyncRequires += `exports.components = {\n${components.map(c => `  "${c.componentChunkName}": () => require("${(0, _path.joinPath)(c.component)}" /* webpackChunkName: "${c.componentChunkName}" */)`).join(`,\n`)}
 }\n\n`;
-    asyncRequires += `exports.data = () => import(/* webpackChunkName: "pages-manifest" */ "${(0, _path.joinPath)(program.directory, `.cache`, `data.json`)}")\n\n`;
+    asyncRequires += `exports.data = () => require(/* webpackChunkName: "pages-manifest" */ "${(0, _path.joinPath)(program.directory, `.cache`, `data.json`)}")\n\n`;

     const writeAndMove = (file, data) => {
       const destination = (0, _path.joinPath)(program.directory, `.cache`, file);

Isso deve funcionar por 0,98

Talvez eu esteja no caminho errado, a mudança produz testes com falha https://github.com/gatsbyjs/gatsby/pull/11331

Ainda não sei por quê.

Então ainda não funciona, certo?

O script de construção é bem-sucedido com minha alteração proposta. Mas não tenho certeza se essa é a solução certa. Então, por favor, teste e analise.

Hm, ou é devido ao novo preset?
https://github.com/gatsbyjs/gatsby/commit/69faca0bff0e2c04e6b3be50bba087284c3dbf6b#diff -a30bb413b08d8091d9187909b256c943

A matriz de plug-ins está correta?

O problema também ocorre em um novo projeto Gatsby e pode ser reproduzido com os testes de CI?

I npm update e o problema foi embora

Forneça uma lista das dependências instaladas (antes e depois da atualização).

@DanielRuf , não consigo reproduzi-lo Acho que foi um acaso, ainda estou recebendo o erro.

Uma solução alternativa é instalar as dependências com Yarn em vez de npm, o que parece funcionar após importar o arquivo de bloqueio npm.

Você pode encontrar meu npm ls com gatsby v2.0.91 (compilação bem-sucedida) e v2.0.93 (falha na compilação) aqui: https://gist.github.com/cyrildurand/f4b70abff19288117ea3996500532774

Ainda tenho o problema com o gatsby 2.0.103

Você tentou instalar as dependências com yarn também?

@cyrildurand
Você encontrou este erro ao instalar npm ?

Eu também tive o mesmo problema, mas atualizar a versão de arcon para 6.0 funcionou bem.

Você encontrou este erro ao instalar o npm?

Este é apenas um aviso e não está relacionado ao problema de Gatsby.

Mesmo erro após a instalação de acorn

funciona com yarn . Eu atualizei a essência com yarn list saída

Mesmo erro após a instalação da bolota

Qual erro?

Tentei atualizar acorn sugerido por @ seonim-ryu e tentei executar gatsby build e tive o mesmo erro "token inesperado" (aquele da primeira mensagem deste problema)

Se eu usar yarn, o problema desaparece e o comando gatsby build bem-sucedido.

Isso também acontece com lançamentos de bolota anteriores? Ou não é essa a causa?

Você tentou minha correção proposta? Não tenho certeza se isso quebraria alguma coisa.

Também falhou com a versão anterior do bolota, não acho que tenha relação com isso.

Está funcionando agora que eu instalo as dependências e não tenho certeza de como aplicar sua proposta corrigida.

Vá para node_modules / gatsby / dist / internal-plugins / query-runner / pages-writer.js e altere os dois import( para require( , consulte também https://github.com/gatsbyjs / gatsby / issues / 11198 # issuecomment -457915157

Funciona com a correção

Algo está quebrado por causa da correção? As compilações de CI com falha não parecem boas.

Possivelmente um problema separado, mas recebi um erro semelhante depois de atualizar para o Gatsby mais recente (2.0.106) e adicionar uma página 404 de acordo com os documentos ('src / pages / 404.js'). O desenvolvimento funcionaria bem, mas a compilação falhou.

Mover a página 404 para sua própria pasta ('src / pages / 404 / index.js') resolveu o erro do meu lado e funciona conforme o esperado (localmente e na implantação no Netlify).

Corrigi o problema excluindo meu arquivo package-lock.json e executei npm install . O novo arquivo package-lock.json gerado tinha muitas diferenças.
Não sei exatamente o que acontece aqui.

Encontrando os mesmos problemas em alguns sites diferentes que tenho. Alguns com exatamente as mesmas dependências e versões ... um acertará os erros, outro não. Começou a acontecer por volta de 2.0.98, acredito, e ainda com 2.0.106. Tentei remover os node_modules, .cache e as pastas públicas, mas também não ajudou. Só acontece na construção, não no desenvolvimento.

@cyrildurand
Renomeei package-lock.json para outra coisa e npm install ed tudo, mas consegui novamente:

error Generating JavaScript bundles failed


  Error: ./.cache/async-requires.js 8:11
  Module parse failed: Unexpected token (8:11)
  You may need an appropriate loader to handle this file type.
  | exports.components = {
  |   "component---node-modules-gatsby-plugin-offline-app-shell-js": function componentNodeModulesGatsbyPluginOfflineAppShellJs() {
  >     return import("/home/foldername/abcrypto/node_modules/gatsby-plugin-offline/app-shell.js"
  |     /* webpackChunkName: "component---node-modules-gatsby-plugin-offline-app-shell-js" */
  |     );
   @ ./.cache/production-app.js 18:0-45 21:23-36 26:23-36

Você limpou sua pasta node_modules ?

Como você faz isso? :(

npm prune node_modules ?

Ou apago tudo manualmente dentro da pasta node_modules?

Edit: Renomeei a pasta node_modules e agora funciona: +1:

• Renomear package-lock.json para outra coisa
• Renomear a pasta node_modules para outra coisa
• npm install na pasta principal

Obrigado @cyrildurand
Editado após a sugestão de @DanielRuf

Basta renomeá-lo para ter um backup.

Então, é realmente apenas um problema com uma dependência desatualizada?

Excluí módulos de nó várias vezes e nunca foi corrigido para mim. apenas as coisas que funcionaram é o yarn ou o arquivo patch acima.

@krazik e você

sim

só para ter certeza de que tentei novamente, e excluindo ambos, posso superar o erro acima, mas agora encontro

Erro: Não é possível encontrar o módulo 'core-js / modules / es6.regexp.to-string'
Erro: Não é possível encontrar o módulo 'core-js / modules / es6.regexp.to-string'

para construir e desenvolver.

error Cannot find module 'core-js/modules/es6.regexp.to-string'


  Error: Cannot find module 'core-js/modules/es6.regexp.to-string'

  - loader.js:611 Function.Module._resolveFilename
    internal/modules/cjs/loader.js:611:15

  - loader.js:537 Function.Module._load
    internal/modules/cjs/loader.js:537:25

  - loader.js:665 Module.require
    internal/modules/cjs/loader.js:665:17

  - helpers.js:20 require
    internal/modules/cjs/helpers.js:20:18

  - render-page.js:3 webpackUniversalModuleDefinition
    /Users/rylanhazelton/dev/Admin/public/render-page.js:3:170

  - render-page.js:10 Object.<anonymous>
    /Users/rylanhazelton/dev/Admin/public/render-page.js:10:3

  - loader.js:736 Module._compile
    internal/modules/cjs/loader.js:736:30

  - loader.js:747 Object.Module._extensions..js
    internal/modules/cjs/loader.js:747:10

  - loader.js:628 Module.load
    internal/modules/cjs/loader.js:628:32

  - loader.js:568 tryModuleLoad
    internal/modules/cjs/loader.js:568:12

  - loader.js:560 Function.Module._load
    internal/modules/cjs/loader.js:560:3

  - loader.js:665 Module.require
    internal/modules/cjs/loader.js:665:17

  - helpers.js:20 require
    internal/modules/cjs/helpers.js:20:18

  - worker.js:32 Promise
    [Admin]/[gatsby]/dist/utils/worker.js:32:35

  - debuggability.js:313 Promise._execute
    [Admin]/[bluebird]/js/release/debuggability.js:313:9

  - promise.js:483 Promise._resolveFromExecutor
    [Admin]/[bluebird]/js/release/promise.js:483:18


error UNHANDLED REJECTION


  Error: Cannot find module 'core-js/modules/es6.regexp.to-string'

  - loader.js:611 Function.Module._resolveFilename
    internal/modules/cjs/loader.js:611:15

  - loader.js:537 Function.Module._load
    internal/modules/cjs/loader.js:537:25

  - loader.js:665 Module.require
    internal/modules/cjs/loader.js:665:17

  - helpers.js:20 require
    internal/modules/cjs/helpers.js:20:18

  - render-page.js:3 webpackUniversalModuleDefinition
    /Users/rylanhazelton/dev/Admin/public/render-page.js:3:170

  - render-page.js:10 Object.<anonymous>
    /Users/rylanhazelton/dev/Admin/public/render-page.js:10:3

  - loader.js:736 Module._compile
    internal/modules/cjs/loader.js:736:30

  - loader.js:747 Object.Module._extensions..js
    internal/modules/cjs/loader.js:747:10

  - loader.js:628 Module.load
    internal/modules/cjs/loader.js:628:32

  - loader.js:568 tryModuleLoad
    internal/modules/cjs/loader.js:568:12

  - loader.js:560 Function.Module._load
    internal/modules/cjs/loader.js:560:3

  - loader.js:665 Module.require
    internal/modules/cjs/loader.js:665:17

  - helpers.js:20 require
    internal/modules/cjs/helpers.js:20:18

  - worker.js:32 Promise
    [Admin]/[gatsby]/dist/utils/worker.js:32:35

  - debuggability.js:313 Promise._execute
    [Admin]/[bluebird]/js/release/debuggability.js:313:9

  - promise.js:483 Promise._resolveFromExecutor
    [Admin]/[bluebird]/js/release/promise.js:483:18

Tente fechar seu editor, exclua .cache, public, node_modules e package-lock.json. Em seguida, faça uma instalação npm.

Tenho certeza de que é apenas uma resolução de pacote funky da NPM.

Eu consegui resolver as dependências em meus sites excluindo o lockfile e node_modules . Não consegui reproduzi-lo fora de sites que estavam quebrados.

Depois de excluir meu package-lock.json , node_modules e instalar usando yarn eu tive outro erro sobre terser-webpack-plugin cannot call minify of undefined (algo parecido). Isso consertou para mim.

Acho que o ecossistema Node.js é realmente o que quebra mais rápido ;-)

A atualização mais recente do terser (lançada há uma hora) quebra esse plugin.

Portanto, este é um novo problema (em uma dependência).

Posso confirmar que são dois problemas diferentes, encontro os dois: https://github.com/gr2m/octokit-rest-documentation/issues/24

O erro do Terser vem dessas linhas

  const {
    error,
    map,
    code,
    warnings
  } = _terser.default.minify({
    [file]: input
  }, terserOptions);

Funciona se você substituir _terser.default.minify por apenas _terser.minify

Também estou tendo esse problema em minhas compilações do Travis CI. Mesmo usando yarn não corrige. Qualquer patch rápido que eu possa usar até que a correção adequada seja lançada? obrigado

O erro do Terser deve ser resolvido agora

terser-webpack-plugin foi corrigido e publicamos 2.0.112 com a nova versão do terser-webpack-plugin

Não tenho certeza se isso está relacionado, mas você pode tentar atualizar?

Nesse ínterim, @DanielRuf @dlindahl poderia criar um link para uma reprodução mínima do problema que está vendo?

Consulte https://github.com/gatsbyjs/gatsby/issues/11198#issuecomment -457905564

@sidharthachatterjee Posso confirmar, atualizar para [email protected] específico resolveu meu problema no Gitlab CI.

O erro do Terser deve ser resolvido agora

confirmado.

Vamos fechar isso. Comente se podemos ajudar mais ou se isso _não está confirmado_ para ser corrigido.

Obrigado a todos!

O erro original para o qual esse problema foi aberto permanece:

Error: ./.cache/async-requires.js 8:11
Module parse failed: Unexpected token (8:11)

@ gr2m você poderia fornecer uma reprodução?

Em qualquer caso - vou reabrir, obrigado!

Eu tinha exatamente o mesmo problema.
A análise do módulo falhou: token inesperado (8:11)
Você pode precisar de um carregador apropriado para lidar com este tipo de arquivo

A correção de fios funcionou para mim.

Excluir .cache / public / node_modules não funcionou.

O problema começou para mim depois de executar a atualização do npm.

Mesmo problema aqui.

    "@magicsoup.io/stock": "0.0.11",
    "@zauberware/react-scroll-to": "^0.1.1",
    "@zauberware/react-svg-assets": "^0.10.2",
    "babel-plugin-styled-components": "^1.10.0",
    "gatsby": "^2.0.115",
    "gatsby-image": "^2.0.29",
    "gatsby-plugin-htaccess": "^1.0.8",
    "gatsby-plugin-manifest": "^2.0.17",
    "gatsby-plugin-offline": "^2.0.22",
    "gatsby-plugin-react-helmet": "^3.0.6",
    "gatsby-plugin-sharp": "^2.0.20",
    "gatsby-plugin-sitemap": "^2.0.5",
    "gatsby-plugin-styled-components": "^3.0.5",
    "gatsby-plugin-web-font-loader": "^1.0.4",
    "gatsby-source-filesystem": "^2.0.20",
    "gatsby-transformer-json": "^2.1.8",
    "gatsby-transformer-remark": "^2.2.4",
    "gatsby-transformer-sharp": "^2.1.13",
    "marksy": "^6.1.0",
    "prop-types": "^15.6.2",
    "react": "^16.7.0",
    "react-dom": "^16.7.0",
    "react-helmet": "^5.2.0",
    "react-i18next": "^10.0.0",
    "react-obfuscate": "^3.0.0",
    "react-slick": "^0.23.2",
    "styled-components": "^4.1.3",
    "styled-normalize": "^8.0.6",
    "styled-system": "^3.2.1",

Tenta carregar um template de src / templates

Error: ./.cache/async-requires.js 8:11
  Module parse failed: Unexpected token (8:11)
  You may need an appropriate loader to handle this file type.
  | exports.components = {
  |   "component---src-templates-markdown-template-js": function componentSrcTemplatesMarkdownTemplateJs() {
  >     return import("/Users/simon/workspaces/web/altstadtdomizil/src/templates/markdownTemplate.js"
  |     /* webpackChunkName: "component---src-templates-markdown-template-js" */
  |     );
   @ ./.cache/production-app.js 18:0-45 21:23-36 26:23-36

gatsby-node.js

exports.createPages = ({ actions, graphql }) => {
  const { createPage } = actions

  const blogPostTemplate = path.resolve(`src/templates/markdownTemplate.js`)

  return graphql(`
    {
      allMarkdownRemark(
        sort: { order: DESC, fields: [frontmatter___title] }
        limit: 1000
      ) {
        edges {
          node {
            frontmatter {
              path
            }
          }
        }
      }
    }
  `).then(result => {
    if (result.errors) {
      return Promise.reject(result.errors)
    }

    result.data.allMarkdownRemark.edges.forEach(({ node }) => {
      createPage({
        path: node.frontmatter.path,
        component: blogPostTemplate,
        context: {}, // additional data can be passed via context
      })
    })
  })
}

Se eu comentar o gatsby-node.js, recebo este erro:

  Error: ./.cache/async-requires.js 8:11
  Module parse failed: Unexpected token (8:11)
  You may need an appropriate loader to handle this file type.
  | exports.components = {
  |   "component---src-pages-404-js": function componentSrcPages404Js() {
  >     return import("/Users/simon/workspaces/web/altstadtdomizil/src/pages/404.js"
  |     /* webpackChunkName: "component---src-pages-404-js" */
  |     );
   @ ./.cache/production-app.js 18:0-45 21:23-36 26:23-36

retornar importação (

Por favor, veja os outros comentários.

Isso aparece nos emblemas / escudos nº 2947 durante a atualização de 2.0.115 para 2.0.116 ou 2.0.117.

Recentemente, mesclei emblemas / escudos # 2949 que atualizou babel-preset-gatsby de 0.1.6 para 0.1.7, embora eu tenha tentado hackear em um downgrade e isso não corrigiu o problema.

O problema foi detectado no CI e se manifesta lá de forma consistente. Nosso IC não preserva .cache , então isso pode ser descartado.

  Error: ./.cache/async-requires.js 8:11
  Module parse failed: Unexpected token (8:11)
  You may need an appropriate loader to handle this file type.
  | exports.components = {
  |   "component---frontend-components-main-js": function componentFrontendCompo  nentsMainJs() {
  >     return import("/home/circleci/project/frontend/components/main.js"
  |     /* webpackChunkName: "component---frontend-components-main-js" */
  |     );
   @ ./.cache/production-app.js 18:0-45 21:23-36 26:23-36

https://circleci.com/gh/badges/shields/39885

Acho que esse pode ser o problema: webpack / webpack # 8656.

Adicionado: os sintomas coincidem e o tempo também se ajusta.

@paulmelnikow boa pegada. E é por isso que recomendo usar o CJS se não tivermos que usar o ESM - ele ainda não é 100% confiável em bundlers. E a outra maneira ainda deve funcionar.

Então, fixar o webpack na raiz package.json deve funcionar?

E é também por isso que o SemVer no ecossistema JS está totalmente quebrado. As atualizações automáticas de dependências (profundas) porque os arquivos de bloqueio só funcionam no nível raiz.

Para ser claro, acorn e a forma como o npm resolve o deptree são o problema e a causa.

https://github.com/webpack/webpack/issues/8656#issuecomment -456010969

Posso reproduzir isso (outra razão pela qual ainda usamos fios no trabalho).

Para ser exato, é um problema do NPM.

https://npm.community/t/packages-with-peerdependencies-are-incorrectly-hoisted/4794/4

https://npm.community/t/release-npm-6-8-0-next-0/5058

Solução: instale a versão mais recente do npm.

Não tenho certeza se concordo com essa avaliação. Isso pode se manifestar no npm e não no yarn devido a diferenças na forma como a resolução ocorre, no entanto, 4.29.3 é uma versão perfeitamente correta para instalar quando um pacote declarou uma dependência de ^ 4.12.0. Isso é o que significa o cursor. Se Gatsby quiser bloquear uma versão específica, pode fazê-lo e, nesse caso, o npm irá honrá-lo.

Webpack é uma dependência de Gatsby, não uma dependência de par.

O problema era o içamento no npm (diferente no Yarn) e acorn não podia ser carregado corretamente devido a isso. Veja a postagem da comunidade Tobias e o comentário vinculado.

Eu sinto que preciso que você explique isso melhor. Eu dei uma olhada nesses tópicos, mas não vejo como eles se aplicam aqui.

Não sei o que está causando o bug no Webpack; entretanto, se concordarmos que Gatsby não deve usar 4.29.3, a dependência do cursor precisa ser alterada.

Funciona com o yarn, é apenas um problema com o npm, em combinação com dependências específicas e o cálculo do deptree. Veja o PR de Tobias.

Veja https://github.com/npm/cli/pull/147/files

Aiiiee te peguei. É esse bug de dependências de pares no npm que está fazendo com que o webpack 4.29 não funcione corretamente.

O que _podemos_ evitar é a instalação do webpack 4.29. E não tenho certeza se existe uma maneira fácil de um usuário final bloquear a versão do webpack. O npm não fornece uma maneira de fazer isso, então os usuários teriam que usar algo como a ferramenta de terceiros npm-force-resolution .

Consulte npm / cli # 152; parece que não podemos esperar uma resolução rápida.

Agora que 2.0.118 vem com um band-aid, os usuários do npm devem estar bem e obviamente não podem usar o webpack 4.29.x independentemente.

Estou certo de que os usuários do yarn podem usar resolutions para forçar o gatsby a usar uma versão posterior fora do intervalo, se quiserem?

@paulmelnikow correto - mas realmente não deve ser necessário e não tenho certeza se há um benefício específico necessário em fazer isso.

Atualizaremos a dependência fixada assim que pudermos (seguindo a questão do npm agora), então deve ser apenas um pontinho para npm usuários em particular.

Obrigado pela correção!

_Agora_ acho que posso fechar isso :)

Confirmado corrigido com a versão 2.0.118!

Foi incrível acompanhar. Obrigado a todos pelo excelente trabalho!

Olá a todos! Gostaria de saber se vocês poderiam dar uma rodada npm install gatsby@webpack-acorn . Queremos atualizar o webpack para a versão mais recente, mas não temos certeza se isso ainda é um problema. Não consegui reproduzir, mas preferimos prevenir do que remediar.

Olá @wardpeet! Agradecemos seu contato.

Eu criei um branch aqui: emblemas / escudos # 3572

Parece que ainda é um problema: https://circleci.com/gh/badges/shields/57401

As etapas para reproduzir localmente seriam clonar esse branch e executar npm ci seguido por npm run build . Sinta-se à vontade para fazer isso, se desejar, ou envie um ping e eu posso atualizar a filial de RP.

@paulmelnikow muito obrigado! Você também poderia me dizer qual versão do node & npm você está usando para que eu possa executá-la com sua configuração também, caso funcione para mim.

Isto é o que tenho localmente:

~/c/shields (bump-webpack-rc|✔) $ node --version
v10.13.0
~/c/shields (bump-webpack-rc|✔) $ npm --version
6.9.0

Em CI, também está acontecendo no Nó 8 (não tenho certeza da versão exata do npm).

O problema é reproduzível em ambos os ambientes.

Obrigado por investigar isso!