Gatsby: Build fails after with "Unexpected token" in `async-requires` after upgrade to 2.0.84

I'm experiencing a similar error after upgrading from 2.0.62 to 2.0.91.

In my case, gatsby develop works fine, but gatsby build errors out on either the template.js page (if I include it) or 404.js (if I remove the createPages snippet from 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

or

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

Everything worked fine before upgrading gatsby. 🤷‍♂️

@dlindahl @ooloth

Can you please link to minimal reproductions of this?

I'm getting the same error using Gatsby v 2.0.55 where package-lock.json is disabled in .npmrc. The site is built from a clean workspace daily. One day it worked, the next it didn't. I'm guessing the error is related to some transient dependency which has changed.

same issue when I upgrade gatsby from v2.0.91 to v2.0.93 (v2.0.92) doesn't exist

Hi, chiming in to say that I am currently also experiencing this issue, but am struggling to build a minimal reproduction for it.

Currently running an npm update on my repository does cause the build to fail, but it does not for my personal website.

I'll keep digging around until I can find what's causing it or someone else figures it out. If I can get it isolated cleanly I'll post back here.

Thanks!

Same here!
I have typed npm update -g npm to get the npm 6.7.0 version and I have gatsby 2.0.98.

gatsby plugin offline version -> 2.0.21

Repository with this problem: there you go.

Also can you list the installed dependencies with npm ls and run node --version?

Bisecting might be helpful here too. I'll test the repo in a few minutes.

Ok same error here. I'll bisect this.

It seems it happens in all versions so it is a plugin or another dependency probably.
Will test further.

I think I found the cause. I'll provide a patch and PR.

@omrllm (a patch for 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);

By changing the import to require it should work. There is probably just a missing loader but why use import here anyway when the ESM way just produces issues and mixing exports with import is never a good 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 />
>     })

Diff after the updater and a new build run @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);

This should work for .98

Maybe I am on the wrong track, the change produces failing tests https://github.com/gatsbyjs/gatsby/pull/11331

Not yet sure why.

So it still doesn't work, right?

The build script succeeds with my proposed change. But I'm not sure if this is the right solution. So please test and review it.

Hm, or is it due to the new preset?
https://github.com/gatsbyjs/gatsby/commit/69faca0bff0e2c04e6b3be50bba087284c3dbf6b#diff-a30bb413b08d8091d9187909b256c943

Is the plugins array correct?

Does the issue also happen in a fresh new Gatsby project and can it be reproduced with the CI tests?

I npm update and the problem went away

Please provide a list of the installed dependencies (before and after the update).

@DanielRuf, I can't reproduce it I guess it was a fluke I am still getting the error.

A workaround is to install the dependencies with Yarn instead of npm which seems to work after importing the npm lockfile.

You can find my npm ls with gatsby v2.0.91 (build succeed) and v2.0.93 (build failed) here : https://gist.github.com/cyrildurand/f4b70abff19288117ea3996500532774

I still have the problem with gatsby 2.0.103

Did you try to install the dependencies with yarn too?

@cyrildurand
Did you encounter this error when you installed npm?

I also had the same issue, but upgrading arcon's version to 6.0 worked well.

Did you encounter this error when you installed npm

This is just a warning and not related to the Gatsby issue.

Same error after the installation of acorn

it works with yarn. I updated the gist with yarn list output

Same error after the installation of acorn

Which error?

I tried upgrading acorn has suggested by @seonim-ryu and try to run gatsby build and had the same, "unexpected token" error (the one from the first message of this isssue)

If I use yarn, the issue disappear, the gatsby build comand succeed.

Does it also happen with previous acorn releases? Or is this not the cause?

Did you try my proposed fix? Not sure if this would break anything.

It also failed with previous version of acorn, I don't think it is related to it.

It is working now that I install the dependencies and I'm not sure on how to apply your proposed fixed.

Go to node_modules/gatsby/dist/internal-plugins/query-runner/pages-writer.js and change the two import( to require(, also see https://github.com/gatsbyjs/gatsby/issues/11198#issuecomment-457915157

It works with the fix

Is anything broken because of the fix? The failing CI builds do not look great.

Possibly a separate issue, but I got a similar error after upgrading to latest Gatsby (2.0.106) and adding a 404 page as per the docs ('src/pages/404.js'). Develop would run fine, but build failed.

Moving 404 page into its own folder ('src/pages/404/index.js') resolved the error on my end and works as expected (locally and on deployment to Netlify).

I fixed the issue by deleting my package-lock.json file and run npm install. The new generated package-lock.json file had lot of differences.
Don't know exactly what happens here.

Running into the same issues across a few different sites I have. Some with the exact same dependencies and versions... one will hit the errors, one will not. It started happening around 2.0.98 I believe and still with 2.0.106. I've tried removing the node_modules, .cache, and public folders, but that hasn't helped either. Only happens on build, not develop.

@cyrildurand
I renamed package-lock.json to something else, and npm installed everything, but I got again:

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

Did you clean your node_modules folder ?

How do you do that? :(

npm prune node_modules?

Or do I delete everything manually inside the node_modules folder?

Edit: I've renamed the node_modules folder and now it works :+1:

• Rename package-lock.json to something else
• Rename node_modules folder to something else
• npm install in the main folder

Thanks @cyrildurand
Edited after the @DanielRuf suggestion

Just rename it to have a backup.

So it is really just an issue with an outdated dependency then?

I deleted node modules multiple times and it never fixed for me. only things that worked is yarn or the patch file above.

@krazik and did you delete/rename package-lock.json?

yes

just to be sure I tried it again, and deleting both I can get past the error above but now run into

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

for both build and develop.

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

Try closing your editor, delete .cache, public, node_modules, and package-lock.json. Then do a npm install.

I'm pretty sure that it's just some funky package resolution by NPM.

I did manage to get the dependencies sorted out on my sites by deleting the lockfile and node_modules. I wasn't able to reproduce it outside of sites that were broken.

After deleting my package-lock.json, node_modules and installing using yarn I had another error about terser-webpack-plugin cannot call minify of undefined (something like that). This fixed it for me.

I guess the Node.js ecosystem is really the fastest breaking one ;-)

The latest terser update (released an hour ago) breaks this plugin.

So this is a new issue (in a dependency).

I can confirm it’s two different issues, I run into both of them: https://github.com/gr2m/octokit-rest-documentation/issues/24

The Terser error comes from these lines

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

It works if you replace _terser.default.minify with just _terser.minify

I'm also experiencing this issue in my Travis CI builds. Even using yarn doesn't fix it. Any quick patch I could use until the proper fix is out? Thanks

The Terser error should be resolved now

terser-webpack-plugin was fixed and we published 2.0.112 with the new version of terser-webpack-plugin

I'm not sure if this is related but can you please try updating?

In the mean time, @DanielRuf @dlindahl could you please link to a minimal reproduction of the issue you're seeing?

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

@sidharthachatterjee I can confirm, upgrading to specific [email protected] solved my problem on Gitlab CI.

The Terser error should be resolved now

confirmed.

Let's close this out. Please comment if we can help further or if this is _not confirmed_ to be fixed.

Thanks all!

The original error that this issue was opened for remains:

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

@gr2m could you provide a reproduction?

In any case--I'll re-open, thanks!

I had the exact same issue.
Module parse failed: Unexpected token (8:11)
You may need an appropriate loader to handle this file type

The yarn fix worked for me.

Deleting .cache/public/node_modules didn't work.

The issue started for me after running npm update.

Same Issue here.

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

Tries to load a template from 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
      })
    })
  })
}

If I comment out the gatsby-node.js I am getting this 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

return import(

Please see the other comments.

This appears in badges/shields#2947 while upgrading from 2.0.115 to either 2.0.116 or 2.0.117.

I recently merged badges/shields#2949 which updated babel-preset-gatsby from 0.1.6 to 0.1.7, though I have tried hacking in a downgrade and that did not fix the problem.

The problem was caught in CI and manifests there consistently. Our CI does not preserve .cache, so that can be ruled out.

  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

I think this may be the issue: webpack/webpack#8656.

Added: Symptoms match and timing fits, too.

@paulmelnikow good catch. And this is why I recommend using CJS if we do not have to use ESM - it is still not 100% reliable in bundlers. And the other way should still work.

So pinning webpack in the root package.json should work?

And this js also why SemVer in the JS ecosystem is totally broken imho. The automatic updates of (deep) deps because the lockfiles only work in the root level.

To be clear, acorn and the way npm resolves the deptree are the issue and cause.

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

I can reproduce this (another reason why we still use yarn at work).

To be exact, it is a npm issue.

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

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

Solution: install latest npm release.

I'm not sure I agree with that assessment. This may manifest in npm and not yarn due to differences in the way resolution takes place, however 4.29.3 is a perfectly correct version to install when a package has declared a dependency on ^4.12.0. That is what the caret means. If Gatsby wants to lock a specific version it is welcome to do so, and in that case npm will honor it.

Webpack is a dependency of Gatsby, not a peer dependency.

The issue is was the hoisting in npm (different in Yarn) and that acorn could not be loaded properly due to this. See Tobias community post and the linked comment.

I feel like I need you to explain that better. I skimmed those threads but don’t see how any it applies here.

I don’t know what is causing the bug in Webpack; however if we agree Gatsby shouldn’t use 4.29.3, the caret dependency needs to be changed.

It works with yarn, it is just an issue with npm, in combination with specific dependencies and the deptree calculation. See the PR of Tobias.

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

Aiiiee gotcha. It's that peer dependencies bug in npm which is what's causing webpack 4.29 not to work correctly.

What we _can_ prevent is the installation of webpack 4.29. And I'm not sure there is an easy way of an end user locking the webpack version. npm doesn't provide a way to do it, so users would have to use something like the third-party tool npm-force-resolutions.

See npm/cli#152; it doesn't look like we can expect a quick resolution.

Now that 2.0.118 ships a band-aid, npm users should be okay, and obviously can’t use webpack 4.29.x regardless.

Am I right that yarn users can use resolutions to force gatsby to use a later, out-of-range version, if they want?

@paulmelnikow correct - but really shouldn't be necessary and I'm not sure there's a particular necessary benefit in doing so.

We'll update the pinned dependency as soon as we are able to (following the npm issue now), so it should be but a blip for npm users in particular.

Thanks for the fix!

_Now_ I think I can close this out :)

Confirmed fixed with the 2.0.118 release!

This was amazing to follow. Thank you all for the amazing work!

Hey all! I wonder if you guys could give npm install gatsby@webpack-acorn a spin. We want to upgrade webpack to the latest version but we're not sure if this is still an issue. I couldn't reproduce it but we rather want to be safe than sorry.

Hi @wardpeet! Thanks for reaching out.

I created a branch here: badges/shields#3572

It looks like it's still an issue: https://circleci.com/gh/badges/shields/57401

Steps to reproduce locally would be to clone that branch and run npm ci followed by npm run build. Feel free to do that if you'd like, or ping me and I can update the PR branch.

@paulmelnikow thanks so much! Could you also tell me what node & npm version you using so I can run it with your setup as well in case it works for me.

This is what I've got locally:

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

In CI it's also happening in Node 8 (not sure the exact npm version).

The problem is reproducible in both environments.

Thanks for looking into it!