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

  1. Inspect the stringified `${curr}` node in the error to identify the offending property and its node type.
  2. Rewrite that option as a plain literal/object literal so the reader can convert it.
  3. 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

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


AI-assisted analysis of gatsbyjs/gatsby@8b06340921 (2026-08-13). Data as JSON: /api/errors/6faac577f21422e0. Report an issue: GitHub.