gatsbyjs/gatsby · error
Did not recognize ${curr}
Error message
Did not recognize ${curr} What it means
Thrown inside `getObjectFromNode` (get-object-from-node.js:51) during the gatsby-recipes AST reader. For each property of an object expression, if `curr.value` is falsy OR not an ObjectExpression handled by the prior branch, the node type is unrecognized and the conversion aborts. The error stringifies the raw Babel AST node, making it useful for diagnostics.
Source
Thrown at deprecated-packages/gatsby-recipes/src/providers/gatsby/utils/get-object-from-node.js:51
}
const getObjectFromNode = nodeValue => {
if (!nodeValue || !nodeValue.properties) {
return getValueFromNode(nodeValue)
}
const props = nodeValue.properties.reduce((acc, curr) => {
let value = null
if (curr.value) {
value = getValueFromNode(curr.value)
} else if (t.isObjectExpression(curr.value)) {
value = curr.value.expression.properties.reduce((acc, curr) => {
acc[getKeyNameFromAttribute(curr)] = getObjectFromNode(curr)
return acc
}, {})
} else {
throw new Error(`Did not recognize ${curr}`)
}
acc[getKeyNameFromAttribute(curr)] = value
return acc
}, {})
return props
}
export default getObjectFromNode
export { getValueFromNode }
View on GitHub (pinned to 8b06340921)
Solutions
- Inspect the stringified `${curr}` node in the error to identify the offending property and its node type.
- Rewrite that option as a plain literal/object literal so the reader can convert it.
- Remove spread elements or dynamic expressions from plugin option objects consumed by recipes.
Example fix
// before — spread element not handled
{
resolve: `gatsby-source-filesystem`,
options: { ...defaults, path: `${__dirname}/src` },
}
// after — literal object
{
resolve: `gatsby-source-filesystem`,
options: { name: `src`, path: `${__dirname}/src` },
} Defensive patterns
Strategy: validation
Validate before calling
const SUPPORTED = ['StringLiteral','NumericLiteral','BooleanLiteral','NullLiteral','ObjectExpression','ArrayExpression']
function objectPropsAreSupported(objectExprNode) {
return objectExprNode.properties.every(p =>
p.type === 'ObjectProperty' && (!p.value || SUPPORTED.includes(p.value.type))
)
} Type guard
function isRecognizableValue(node) {
return !node || ['StringLiteral','NumericLiteral','BooleanLiteral','NullLiteral','ObjectExpression','ArrayExpression'].includes(node.type)
} Prevention
- Avoid SpreadElement and dynamic expressions in plugin option objects used by recipes.
- Use literal values for plugin options.
- Inspect the stringified AST node in the error to diagnose the offending property.
When it happens
Trigger: Recipe config containing a property whose value is a node type the reader does not handle — e.g. a SpreadElement, an ArrayExpression of non-literals, a ConditionalExpression, a TemplateLiteral with interpolation, or a property shorthand.
Common situations: Writing plugin options in gatsby-config.js that use spreads (`...baseOptions`), ternaries, or computed keys that gatsby-recipes' static reader was not taught to parse; adding novel plugin option shapes.
Related errors
- Your gatsby-config.js format is currently not supported by G
- MissingInfoError
- A recipe must be specified
- ${JSON.stringify(result)}
- {"fetchError":"Could not fetch ${pathOrUrl} from official re
AI-assisted analysis of gatsbyjs/gatsby@8b06340921 (2026-08-13).
Data as JSON: /api/errors/6faac577f21422e0.
Report an issue: GitHub.