Gatsby: La compilación falla después con "Token inesperado" en `async-requiere` después de la actualización a 2.0.84

Estoy experimentando un error similar después de actualizar de 2.0.62 a 2.0.91 .

En mi caso, gatsby develop funciona bien, pero gatsby build errores en la página template.js (si la incluyo) o 404.js (si elimino el createPages fragmento 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

o

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

Todo funcionó bien antes de actualizar gatsby . 🤷‍♂️

@dlindahl @ooloth

¿Puede vincular a reproducciones mínimas de esto?

Recibo el mismo error al usar Gatsby v 2.0.55 donde package-lock.json está deshabilitado en .npmrc. El sitio se construye a partir de un espacio de trabajo limpio a diario. Un día funcionó, al siguiente no. Supongo que el error está relacionado con alguna dependencia transitoria que ha cambiado.

el mismo problema cuando actualizo gatsby de v2.0.91 a v2.0.93 ( v2.0.92 ) no existe

Hola, intervengo para decir que actualmente también estoy experimentando este problema, pero estoy luchando por construir una reproducción mínima para él.

Actualmente, ejecutar un npm update en mi repositorio hace que la compilación falle, pero no para mi sitio web personal .

Seguiré investigando hasta que pueda encontrar la causa o alguien más se dé cuenta. Si puedo aislarlo limpiamente, lo publicaré aquí.

¡Gracias!

¡Igual que aquí!
He escrito npm update -g npm para obtener la versión npm 6.7.0 y tengo gatsby 2.0.98.

versión sin conexión del complemento gatsby -> 2.0.21

Repositorio con este problema: ahí lo tienes .

¿También puede enumerar las dependencias instaladas con npm ls y ejecutar node --version ?

La bisección también puede ser útil aquí. Probaré el repositorio en unos minutos.

Ok mismo error aquí. Cortaré esto en dos.

Parece que sucede en todas las versiones, por lo que probablemente sea un complemento u otra dependencia.
Probará más.

Creo que encontré la causa. Proporcionaré un parche y relaciones públicas.

@omrllm (un parche 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);

Al cambiar import a require debería funcionar. Probablemente solo falta un cargador, pero ¿por qué usar import aquí de todos modos cuando la forma de ESM solo produce problemas y mezclar exports con import nunca es una buena idea?

+ [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 />
>     })

Diferencia después del actualizador y una nueva compilación ejecute @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);

Esto debería funcionar para .98

Quizás estoy en el camino equivocado, el cambio produce pruebas fallidas https://github.com/gatsbyjs/gatsby/pull/11331

Aún no estoy seguro de por qué.

Entonces todavía no funciona, ¿verdad?

El script de compilación tiene éxito con mi cambio propuesto. Pero no estoy seguro de si esta es la solución correcta. Así que pruébelo y revíselo.

Hm, ¿o se debe al nuevo preajuste?
https://github.com/gatsbyjs/gatsby/commit/69faca0bff0e2c04e6b3be50bba087284c3dbf6b#diff -a30bb413b08d8091d9187909b256c943

¿Es correcta la matriz de complementos?

¿El problema también ocurre en un nuevo proyecto de Gatsby y se puede reproducir con las pruebas de CI?

I npm update y el problema desapareció

Proporcione una lista de las dependencias instaladas (antes y después de la actualización).

@DanielRuf , no puedo reproducirlo. Supongo que fue una casualidad. Sigo recibiendo el error.

Una solución alternativa es instalar las dependencias con Yarn en lugar de npm, que parece funcionar después de importar el archivo de bloqueo npm.

Puede encontrar mi npm ls con gatsby v2.0.91 (compilación exitosa) y v2.0.93 (compilación fallida) aquí: https://gist.github.com/cyrildurand/f4b70abff19288117ea3996500532774

Todavía tengo el problema con gatsby 2.0.103

¿Intentaste instalar las dependencias con yarn también?

@cyrildurand
¿Encontró este error cuando instaló npm ?

También tuve el mismo problema, pero la actualización de la versión de arcon a 6.0 funcionó bien.

¿Encontró este error cuando instaló npm?

Esto es solo una advertencia y no está relacionado con el problema de Gatsby.

Mismo error después de la instalación de acorn

funciona con yarn . Actualicé la esencia con yarn list salida

Mismo error después de la instalación de bellota.

¿Qué error?

Intenté actualizar acorn sugerido por @ seonim-ryu e intenté ejecutar gatsby build y tuve el mismo error de "token inesperado" (el del primer mensaje de este número)

Si utilizo hilo, el problema desaparece, el comando gatsby build éxito.

¿Ocurre también con lanzamientos anteriores de bellotas? ¿O no es esta la causa?

¿Probaste mi solución propuesta? No estoy seguro de si esto rompería algo.

También falló con la versión anterior de bellota, no creo que esté relacionado con ella.

Está funcionando ahora que instalo las dependencias y no estoy seguro de cómo aplicar la solución propuesta.

Vaya a node_modules / gatsby / dist / internal-plugins / query-runner / pages-writer.js y cambie los dos import( a require( , también consulte https://github.com/gatsbyjs / gatsby / issues / 11198 # issuecomment -457915157

Funciona con la solución

¿Hay algo roto debido a la reparación? Las compilaciones de CI defectuosas no se ven muy bien.

Posiblemente sea un problema separado, pero obtuve un error similar después de actualizar a la última versión de Gatsby (2.0.106) y agregar una página 404 según los documentos ('src / pages / 404.js'). Desarrollar funcionaría bien, pero la compilación falló.

Mover la página 404 a su propia carpeta ('src / pages / 404 / index.js') resolvió el error por mi parte y funciona como se esperaba (localmente y en la implementación en Netlify).

Solucioné el problema eliminando mi archivo package-lock.json y ejecuté npm install . El nuevo archivo package-lock.json generado tenía muchas diferencias.
No sé exactamente qué pasa aquí.

Tengo los mismos problemas en algunos sitios diferentes que tengo. Algunos con exactamente las mismas dependencias y versiones ... uno encontrará los errores, el otro no. Comenzó a suceder alrededor de 2.0.98 creo y todavía con 2.0.106. Intenté eliminar los node_modules, .cache y las carpetas públicas, pero eso tampoco ayudó. Solo ocurre en la construcción, no en el desarrollo.

@cyrildurand
Cambié el nombre de package-lock.json a otra cosa, y npm install ed todo, pero obtuve de nuevo:

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

¿Limpiaste tu carpeta node_modules ?

¿Cómo haces eso? :(

npm prune node_modules ?

¿O elimino todo manualmente dentro de la carpeta node_modules?

Editar: he cambiado el nombre de la carpeta node_modules y ahora funciona: +1:

• Cambiar el nombre de package-lock.json a otra cosa
• Cambiar el nombre de la carpeta node_modules a otra cosa
• npm install en la carpeta principal

Gracias @cyrildurand
Editado después de la sugerencia de @DanielRuf

Simplemente cámbiele el nombre para tener una copia de seguridad.

Entonces, ¿es realmente solo un problema con una dependencia desactualizada?

Eliminé módulos de nodo varias veces y nunca se solucionó para mí. Lo único que funcionó es el hilo o el archivo de parche anterior.

@krazik y ¿

si

solo para asegurarme de que lo intenté de nuevo, y al eliminar ambos puedo superar el error anterior, pero ahora me encuentro

Error: no se puede encontrar el módulo 'core-js / modules / es6.regexp.to-string'
Error: no se puede encontrar el módulo 'core-js / modules / es6.regexp.to-string'

tanto para construir como para desarrollar.

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

Intente cerrar su editor, elimine .cache, public, node_modules y package-lock.json. Luego haga una instalación de npm.

Estoy bastante seguro de que es solo una resolución de paquete original de NPM.

Me las arreglé para ordenar las dependencias en mis sitios eliminando el archivo de bloqueo y node_modules . No pude reproducirlo fuera de los sitios que estaban dañados.

Después de eliminar mi package-lock.json , node_modules e instalar usando yarn , tuve otro error sobre terser-webpack-plugin cannot call minify of undefined (algo así). Esto me lo arregló.

Supongo que el ecosistema Node.js es realmente el que se rompe más rápido ;-)

La última actualización de terser (lanzada hace una hora) rompe este complemento.

Entonces este es un problema nuevo (en una dependencia).

Puedo confirmar que son dos problemas diferentes, me encuentro con ambos: https://github.com/gr2m/octokit-rest-documentation/issues/24

El error de Terser proviene de estas líneas

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

Funciona si reemplaza _terser.default.minify con solo _terser.minify

También estoy experimentando este problema en mis compilaciones de Travis CI. Incluso usar yarn no lo soluciona. ¿Algún parche rápido que pueda usar hasta que salga la solución adecuada? Gracias

El error de Terser debería resolverse ahora

terser-webpack-plugin se corrigió y publicamos 2.0.112 con la nueva versión de terser-webpack-plugin

No estoy seguro de si esto está relacionado, pero ¿puedes intentar actualizar?

Mientras tanto, @DanielRuf @dlindahl, ¿ podría vincular a una reproducción mínima del problema que está viendo?

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

@sidharthachatterjee Puedo confirmar, la actualización a [email protected] específico resolvió mi problema en Gitlab CI.

El error de Terser debería resolverse ahora

confirmado.

Cerremos esto. Por favor comente si podemos ayudar más o si esto _no está confirmado_ para ser arreglado.

¡Gracias a todos!

El error original por el que se abrió este problema sigue siendo:

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

@ gr2m ¿ podría proporcionar una reproducción?

En cualquier caso, volveré a abrir, ¡gracias!

Yo tuve exactamente el mismo problema.
Error de análisis del módulo: token inesperado (8:11)
Es posible que necesite un cargador adecuado para manejar este tipo de archivo

La solución de hilo funcionó para mí.

Eliminar .cache / public / node_modules no funcionó.

El problema comenzó después de ejecutar la actualización npm.

Mismo problema aquí.

    "@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",

Intenta cargar una plantilla desde 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
      })
    })
  })
}

Si comento el gatsby-node.js, aparece este error:

  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

devolución de importación

Consulte los otros comentarios.

Esto aparece en insignias / escudos # 2947 al actualizar de 2.0.115 a 2.0.116 o 2.0.117.

Recientemente fusioné insignias / escudos # 2949 que actualizó babel-preset-gatsby de 0.1.6 a 0.1.7, aunque intenté piratear en una degradación y eso no solucionó el problema.

El problema quedó atrapado en CI y se manifiesta allí de manera constante. Nuestro CI no conserva .cache , por lo que puede descartarse.

  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

Creo que este puede ser el problema: webpack / webpack # 8656.

Agregado: los síntomas coinciden y el tiempo también se ajusta.

@paulmelnikow buena captura. Y es por eso que recomiendo usar CJS si no tenemos que usar ESM, todavía no es 100% confiable en paquetes. Y la otra forma debería funcionar.

Entonces, ¿anclar el paquete web en el paquete raíz .json debería funcionar?

Y esto también es la razón por la que SemVer en el ecosistema JS está totalmente roto en mi humilde opinión. Las actualizaciones automáticas de departamentos (profundos) porque los archivos de bloqueo solo funcionan en el nivel raíz.

Para ser claros, acorn y la forma en que npm resuelve el departamento son el problema y la causa.

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

Puedo reproducir esto (otra razón por la que todavía usamos hilo en el trabajo).

Para ser exactos, es un problema de 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

Solución: instale la última versión de npm.

No estoy seguro de estar de acuerdo con esa evaluación. Esto puede manifestarse en npm y no en yarn debido a las diferencias en la forma en que se realiza la resolución, sin embargo 4.29.3 es una versión perfectamente correcta para instalar cuando un paquete ha declarado una dependencia en ^ 4.12.0. Eso es lo que significa el símbolo de intercalación. Si Gatsby quiere bloquear una versión específica, puede hacerlo y, en ese caso, npm la respetará.

Webpack es una dependencia de Gatsby, no una dependencia de pares.

El problema era el izado en npm (diferente en Yarn) y que acorn no se pudo cargar correctamente debido a esto. Vea la publicación de la comunidad de Tobias y el comentario vinculado.

Siento que necesito que me lo expliques mejor. Hojeé esos hilos, pero no veo cómo se aplica aquí.

No sé qué está causando el error en Webpack; sin embargo, si estamos de acuerdo en que Gatsby no debería usar 4.29.3, es necesario cambiar la dependencia de intercalación.

Funciona con hilo, es solo un problema con npm, en combinación con dependencias específicas y el cálculo del departamento. Ver el PR de Tobias.

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

Aiiiee te tengo. Es ese error de dependencias de pares en npm lo que hace que el paquete web 4.29 no funcione correctamente.

Lo que _podemos_ evitar es la instalación de webpack 4.29. Y no estoy seguro de que haya una manera fácil de que un usuario final bloquee la versión del paquete web. npm no proporciona una forma de hacerlo, por lo que los usuarios tendrían que usar algo como la herramienta de terceros npm-force-resolution .

Ver npm / cli # 152; no parece que podamos esperar una resolución rápida.

Ahora que 2.0.118 incluye una curita, los usuarios de npm deberían estar bien y, obviamente, no pueden usar el paquete web 4.29.x independientemente.

¿Tengo razón en que los usuarios de hilo pueden usar resolutions para obligar a Gatsby a usar una versión posterior fuera de rango, si así lo desean?

@paulmelnikow tiene razón, pero en realidad no debería ser necesario y no estoy seguro de que haya un beneficio necesario en particular al hacerlo.

Actualizaremos la dependencia anclada tan pronto como podamos (siguiendo el problema de npm ahora), por lo que debería ser solo un problema para los usuarios de npm en particular.

¡Gracias por la solución!

_Ahora_ creo que puedo cerrar esto :)

¡Confirmado arreglado con la versión 2.0.118!

Esto fue increíble de seguir. ¡Gracias a todos por el increíble trabajo!

¡Oigan todos! Me pregunto si ustedes podrían darle un giro a npm install gatsby@webpack-acorn . Queremos actualizar el paquete web a la última versión, pero no estamos seguros de si esto sigue siendo un problema. No pude reproducirlo, pero queremos prevenir que lamentar.

Hola @wardpeet! Gracias por contactarnos.

Creé una rama aquí: insignias / escudos # 3572

Parece que sigue siendo un problema: https://circleci.com/gh/badges/shields/57401

Los pasos para reproducir localmente serían clonar esa rama y ejecutar npm ci seguido de npm run build . No dude en hacer eso si lo desea, o envíeme un ping y puedo actualizar la sucursal de relaciones públicas.

@paulmelnikow ¡muchas gracias! ¿Podría también decirme qué versión de node & npm está utilizando para que pueda ejecutarlo con su configuración también en caso de que funcione para mí?

Esto es lo que tengo localmente:

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

En CI también está sucediendo en el Nodo 8 (no estoy seguro de la versión exacta de npm).

El problema es reproducible en ambos entornos.

¡Gracias por investigarlo!