The new gatsby-adapter-netlify plugin is causing build failures for Gatsby sites with trailingSlash set to never:
error Adapter gatsby-adapter-netlify is not compatible with following settings:
- trailingSlash option never. Supported option: always
Gatsby functions aren’t deploying either:
Dependencies installation error
────────────────────────────────────────────────────────────────
Error message
A Netlify Function failed to require one of its dependencies.
Please make sure it is present in the site's top-level package.json.
In file /opt/build/repo/.netlify/functions-internal/subscribe-js/subscribe-js.js
Cannot find module 'encoding'
Require stack:
- /opt/buildhome/node-deps/node_modules/@netlify/zip-it-and-ship-it/dist/runtimes/node/bundlers/zisi/resolve.js
We are running into the same exact issue. We are on Gatsby 5.2.0 and do not wish to update to 5.12.0 to use the new gatsby adapter on netlify. Could this be an issue on Netlifys end where they are forcing adapter usage on older versions of gatsby too, accidentally?
+1 on the trailingSlash error.
Gatsby versions up to v5.11.0 should be fine to use as of now.
@hrishikesh - Understood that < 5.12 will still work, however we’re already on 5.12 and in the process of migrating over from Gatsby Cloud.
It seems that netlify adapter restricts to ‘always’ based on its config.
Not providing support for all options has an impact on SEO.
A few questions:
Thank you!
Does this error mean that Gatsby Functions created within plugins/themes won’t work and will need to be refactored?
AFAICT Netlify doesn’t support more than one functions directory in the config.
@techfg right now, if you need the previous behaviour that was more close to what you might have had on Gatsby Cloud, it’s better to use Gatsby 5.11 with gatsby-plugin-netlify instead of using the adapter. The adapter would be the better option in future, but it’s probably not going to be immediate. The only way to not use an adapter is to use a previous Gatsby version (5.11 or 5.10). gatsby-plugin-netlify would not work with the adapter.
@0x0Bop not sure where you got that from. The error shared by @sandren has nothing to do with refactoring your code. Netlify supports just 1 functions directory, but Gatsby API and functions are bundled by Netlify separately.
Thanks for your reply, reading back I can see it’s unclear. The error suggests to move the dependency of the api/{some-function} into the top site package. If it is being caused by a gatsby-plugin or gatsby-theme using the api/ feature, I suppose I’m thinking that if the /api feature is unreliable in plugins then a refactor to minimise their use in the implementation might be a wise move.
I’ve managed to recreate this error while trying to figure out why my functions & SSR don’t get bundled (locally via netlify build) however, I removed many of the functions that import 3rd libs and now it builds locally but nearly always freezes before trying to deploy. I’ve narrowed it down to a “node-fetch” import.
Following the instructions in the error resolves the issue, but my point is that it shouldn’t be necessary.
Gatsby sites that fail to build on Netlify are deploying just fine on Gatsby Cloud and Vercel. I would hope that gatsby-adapter-netlify would reach feature parity rather than requiring everyone that uses Gatsby functions to change their code.
Yeah I’ve managed to deploy functions on a local build by fixing the error, just about to try via Netlify deploy.
Am I correct in thinking that any library imported into a server function would need the same treatment, IE a dependency at the root of the site? IE graphql-request. In many ways this is a breaking change for plugins/themes utilising the gatsby-functions /api.
Does anyone happen to know if this dependency config behaviour is the same when using the essential gatsby plugin alongside 5.11.0 ?
Thanks
If you mean that you need to install a dependency in your package.json that you use in your Gabtsby functions then yes, you definitely need to do that and this is not something a plugin or adapter can fix for you.
I don’t see how this is a breaking change, unless you were listing your dependencies for your server-side functionality elsewhere.
Would be the same with 5.11.0 gatsby-plugin-netlify?
It’s a breaking change in that if someone develops a plugin or theme, say that creates an endpoint via gatsby functions /api for some kind of webhook, like stripe, then without instructions the end consumer of the plugin/theme needs to know to install the critical libs at the root of the site package.json. Without looking into the source code (or the error, which won’t list all the libs on one error) how will they know what those libs are?
Perhaps this is something that Netlify should say in the gatsbyJS docs somewhere.
If you put it that way, in the scenario that you describe, let’s take an example:
|- your project
|-|- package.json -> the top-level package.json that we're talking about
This package.json lists gatsby-theme-something as a dependency.
|- gatsby-theme-something
|-|- package.json
This package.json must list axios as a dependency (an example), if it uses that in its code. devDependecies might not work as Functions are bundled with NODE_ENV=production. As long as it’s listed in dependencies, npm (or any other package manager for that matter) would install it on the disk and it would be bundled by Netlify.
Are you saying that this exact setup is not working?
Firstly, thanks for the info and support, I understand what you’re explaining.
Secondly, apologies to everyone for hijacking.
Thirdly, my issue is pebcak, apologies again. I misconfigured the monorepo build settings.
My situation isn’t quite as hrishikesh describes as I’m using yarn workspaces, the root directory is a container of “workspaces”. This is the outline shape of repo,
gatsby-theme-main-entry - pulling from this repo @netlify build,
|- gatsby-theme-main-entry → [rootDir]
|
|-|-example-site
|-|-packages-|-gatsby-theme-mdx
|-|-packages-|-gatsby-theme-wordpress
|-| package.json (1)
// package.json (1)
{
"name": "gatsby-theme-main-entry",
"version": "0.0.1",
"description": "a container of yarn workspaces",
"workspaces": [
"example-site",
"packages/*"
],
"scripts": {
"build": "yarn workspace example-site build",
"build:clean": "yarn workspace example-site build:clean",
"build:clean:serve": "yarn workspace example-site build:clean:serve",
"clean": "yarn workspace example-site clean",
"serve": "yarn workspace example-site serve",
"test": "yarn workspace example-site test"
},
"dependencies": {
"node-fetch": "^3.3.2"
},
"engines": {
"node": ">=18.0.0"
}
}
What’s describe in hrishikesh example, the top-level package.json, in my situation is actually a workspace called example-site, and this can then consume themes included within the packages/* as a dependency. Allowing gastby-theme creation on the fly. Create a new dir in packages/* and include it in example-site package.json && gatsby-config and it’s good to go.
The site builds locally via netlify build and it also builds on Netlify but without the functions.
My build config is,
Base Dir:
Package Dir:
Build command: npm run build
Publish directory: example-site/public
As you can see, i’ve installed node-fetch as a dependency of the root dir, and this does successfully build locally, but now I’m wondering if I should change Package Dir to example-site ?
Yes!
Moved the node-fetch back into into example-site.package.json (removed from root pkg.json) and set the Package Dir to example-site.
Now my functions are deploying!