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
- updates packages except gatsby see https://github.com/gatsbyjs/gatsby/issues/11198 — committed to cyrildurand/calgary by cyrildurand 5 years ago
- updates packages except gatsby see https://github.com/gatsbyjs/gatsby/issues/11198 (#9) — committed to cyrildurand/calgary by cyrildurand 5 years ago
- rollback gatsby to 2.0.91 see https://github.com/gatsbyjs/gatsby/issues/11198 — committed to cyrildurand/calgary by cyrildurand 5 years ago
- fix(gatsby): Pin webpack to fix `gatsby build` problem This addresses #11198. There's a regression bug webpack/webpack#8656 affecting 4.29.0 through at least 4.29.3 which causes errors like this dur... — committed to paulmelnikow/gatsby by paulmelnikow 5 years ago
- fix(gatsby): Pin webpack to fix `gatsby build` problem This addresses #11198. There's a regression bug webpack/webpack#8656 affecting 4.29.0 through at least 4.29.3 which causes errors like this dur... — committed to paulmelnikow/gatsby by paulmelnikow 5 years ago
- fix(gatsby): Pin webpack to fix `gatsby build` problem This addresses #11198. There's a regression bug webpack/webpack#8656 affecting 4.29.0 through at least 4.29.3 which causes errors like this dur... — committed to paulmelnikow/gatsby by paulmelnikow 5 years ago
- fix(gatsby): Pin webpack to fix `gatsby build` problem This addresses #11198. There's a regression bug webpack/webpack#8656 affecting 4.29.0 through at least 4.29.3 which causes errors like this dur... — committed to paulmelnikow/gatsby by paulmelnikow 5 years ago
- fix(gatsby): pin webpack to fix unexpected token error during build (#11640) ## Description This addresses #11198. There's a regression bug webpack/webpack#8656 affecting 4.29.0 through at leas... — committed to gatsbyjs/gatsby by paulmelnikow 5 years ago
- fix(gatsby): pin webpack to fix unexpected token error during build (#11640) ## Description This addresses #11198. There's a regression bug webpack/webpack#8656 affecting 4.29.0 through at leas... — committed to gurpreet-hanjra/gatsby by paulmelnikow 5 years ago
- [WIP] Update gatsby to a later webpack version https://github.com/gatsbyjs/gatsby/issues/11198#issuecomment-502134101 — committed to badges/shields by paulmelnikow 5 years ago
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.jsonfile and runnpm install. The new generatedpackage-lock.jsonfile 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
npmusers 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
yarndoesn’t fix it. Any quick patch I could use until the proper fix is out? ThanksJust rename it to have a backup.