gatsby: v2: Local gatsby-ssr.js is not run anymore on a static build.
Not sure what the deal here is, but trying my onRenderBody hook is no longer run when doing a gatsby build
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 23 (13 by maintainers)
Commits related to this issue
- fix: gatsby-ssr.js export silently not defined (no error) when imported in gatsby build process see https://github.com/gatsbyjs/gatsby/issues/4718 — committed to adobe/gatsby-add-launch-script by shazron 4 years ago
- Fix onRenderBody not being called https://github.com/gatsbyjs/gatsby/issues/4718 — committed to vrymel/is-it-100k-yet by vrymel 3 years ago
Oh ok, so es6 is already working. Tried this and it worked fine:
Faced this issue several weeks ago, it was a problem that export with default functions doesn’t work, but arrow function work. (I prefer normal functions when I can).
export function ...- didn’t workexport const ... = () => {}- workedOk spent some time tracking down the cause of this with @pieh (thanks!). Using this
gatsby-ssr.jsfile as an example:The bug is caused by using an ES6 module
importwith a CommonJSexports(@jquense pointed this out already), which causes theexportsto be ignored by webpack.Why this happens is - using
importmeans the module is treated as an ES6 module (import / export) instead of a CommonJS module (require / modules.exports / exports).As
gatsby-ssr.jsis treated as an ES6 module,exportsdoesn’t do anything and should be undefined. However, this transformed module ends up in a bundlerender-page.js, which gets run in a Node environment.When running in a Node environment,
exportsdefaults to{}:Which means that the onRenderBody definition
exports.onRenderBody =does not error (exportsis defined), and also does not get exported (exportsis not anexport). It just silently gets defined and then sits there doing nothing.So
onRenderBodydoes not get exported, meaning it doesn’t get called by theapiRunner.One “fix” is to not use
importwithexports(related: https://github.com/webpack/webpack/issues/4039#issuecomment-273804003), but we can’t really control that.I’ve opened a PR that hacks in a very basic fix, just prepending
exports=nullto the beginning of the webpack bundle.This will throw:
if you try and use
exportsin an ES6 module. Which is one step better than silent failure.I think throwing a helpful error describing how to update your file is the best way to resolve this.
We could do it with eslint? But people can override that. Carry on down the static analysis path we’re already using to load plugins? Something else?
Example inputs / outputs for `gatsby-ssr.js`
ES6 Module import, CommonJS exports
This silently fails.
note the
/*! no exports provided */and__webpack_exports__being passed in.Full CommonJS
This works.
Here it’s
/*! no static exports found */andexportsis passed in instead of__webpack_exports__This information needs to be added to the docs as its vital to getting gatsby-ssr.js file to work.
I can only get this to work with mixing commonjs imports, and es6 exports.
If I use commonjs exports, like
exports.onRenderBody, it will “fail” “silently”.