Reusing default Blockquote component for custom PortableText style

I understand you're trying to reuse the default blockquote rendering for a custom "pullquote" style in Portable Text. Your approach of importing from @sanity/form-builder is not the recommended way, and this pattern has actually changed significantly in recent Sanity Studio versions.

The Issue with Your Approach

Importing internal components like Blockquote from @sanity/form-builder/lib/inputs/PortableText/Text/Blockquote is:

1. Accessing private/internal APIs that aren't meant to be public
2. Not documented or supported officially
3. Likely to break between Studio versions since these internal paths can change

The blockEditor.render property you're using was actually deprecated in Sanity Studio v3.1+. According to the migration documentation, the modern approach uses a component property instead.

The Modern Approach (Studio v3+)

Instead of trying to reuse the default blockquote component, you should configure your schema like this:

{
  type: 'block',
  styles: [
    {title: 'Normal', value: 'normal'},
    {title: 'Pull Quote', value: 'pullquote'},
    // other styles...
  ]
}

Then handle the rendering on the frontend when you display the Portable Text content. If you want pullquotes to look like blockquotes, simply map them in your serializer:

import {PortableText} from '@portabletext/react'

const components = {
  block: {
    pullquote: ({children}) => <blockquote>{children}</blockquote>,
  }
}

<PortableText value={content} components={components} />

If You Need Custom Studio Rendering

If you specifically want to customize how the pullquote appears in the Studio editor (not just the frontend), the modern way is described in the Customize the Portable Text Editor documentation. You'd use the component property instead of blockEditor.render:

{
  title: 'Pull Quote',
  value: 'pullquote',
  component: MyCustomPullquoteComponent, // Your own component
}

Bottom line: There isn't an officially supported way to directly reuse Sanity's internal default components. The separation between schema configuration (what styles exist) and rendering (how they appear) is intentional. Configure your styles in the schema, then handle the visual presentation in your serializers/components where you have full control.