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

Description

Running rm -rf .cache && rm -rf public && gatsby-build works fine under 2.0.83. After upgrading to 2.0.84, an error is thrown, aborting the build.

Steps to reproduce

The only I am taking is running gatsby build. After downgrading back to 2.0.83, the issue disappears.

Expected result

The build should complete successfully

Actual result

The build quits with the following error:

success onPostBootstrap — 0.202 s

info bootstrap finished - 6.171 s


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("/Users/dereklindahl/Work/APP/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

Environment

npx gatsby info -- --clipboard                 

  System:
    OS: macOS High Sierra 10.13.6
    CPU: (4) x64 Intel(R) Core(TM) i5-7360U CPU @ 2.30GHz
    Shell: 5.4.2 - /usr/local/bin/zsh
  Binaries:
    Node: 10.14.0 - ~/.nodenv/versions/10.14.0/bin/node
    Yarn: 1.12.3 - /usr/local/bin/yarn
    npm: 6.4.1 - ~/.nodenv/versions/10.14.0/bin/npm
  Languages:
    Python: 2.7.10 - /usr/bin/python
  Browsers:
    Chrome: 71.0.3578.98
    Firefox: 63.0.3
    Safari: 12.0.2
  npmPackages:
    gatsby: 2.0.84 => 2.0.84 
    gatsby-image: ^2.0.25 => 2.0.25 
    gatsby-mdx: ^0.2.0 => 0.2.0 
    gatsby-plugin-canonical-urls: ^2.0.8 => 2.0.8 
    gatsby-plugin-google-analytics: ^2.0.8 => 2.0.8 
    gatsby-plugin-manifest: ^2.0.13 => 2.0.13 
    gatsby-plugin-netlify: ^2.0.6 => 2.0.6 
    gatsby-plugin-netlify-cache: ^1.0.0 => 1.0.0 
    gatsby-plugin-offline: ^2.0.21 => 2.0.21 
    gatsby-plugin-react-helmet: ^3.0.5 => 3.0.5 
    gatsby-plugin-sharp: ^2.0.17 => 2.0.17 
    gatsby-plugin-sitemap: ^2.0.4 => 2.0.4 
    gatsby-plugin-sri: ^1.0.4 => 1.0.4 
    gatsby-plugin-styled-components: ^3.0.4 => 3.0.4 
    gatsby-plugin-zopfli: ^1.0.2 => 1.0.2 
    gatsby-source-filesystem: ^2.0.12 => 2.0.12 
    gatsby-transformer-sharp: ^2.1.10 => 2.1.10 

I saw #10038 which sounded familiar, but my Webpack config is uninteresting:

// gatsby-node.js
exports.onCreateWebpackConfig = ({ actions }) => {
  actions.setWebpackConfig({
    module: {
      rules: [
        {
          test: /\.ogv$/,
          use: [
            {
              loader: require.resolve(`url-loader`),
              options: { limit: 10000, name: 'static/[name]-[hash].[ext]' }
            }
          ]
        }
      ]
    },
    resolve: {
      alias: {
        '@': path.resolve(__dirname, 'src/components')
      },
      modules: [path.resolve(__dirname, 'src'), 'node_modules']
    }
  })
}

And commenting that block out does not fix the error.

If I replace gatsby-plugin-offline with gatsby-plugin-remove-serviceworker, the problem remains, but with a different async import.

FWIW, I do not notice a difference in the contents of async-require.js in the 2.0.83 or 2.0.84 builds and upgrading gatsby-plugin-offline made no difference as well.

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 30
  • Comments: 81 (52 by maintainers)

Commits related to this issue

Most upvoted comments

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

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

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

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.

Confirmed fixed with the 2.0.118 release!

@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 😃

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.

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

Just rename it to have a backup.