Error with top-level await while running data migration script

1 replies
Last updated: May 26, 2023
Hello! I am trying to write some data migration scripts and started with something basic and am running into an error that, while it is not really a Sanity issue, it is while I’m running through
sanity exec
and was not sure if that had anything to do with it. I’m running my command as such from the root of my Sanity project
sanity exec ./scripts/migration/migrateBlips.ts --with-user-token
and my code which is pretty straight forward gives me the error
Top-level await is currently not supported with the "cjs" output format
Here is my code

import { getCliClient } from 'sanity/cli';


const client = getCliClient().withConfig({ apiVersion: '2023-05-24' })

const loadCategories = async () => {
    const categories = await client.fetch('*[_type == "category"]');
    categories.forEach(category => {
        console.log(category)
    });
}

try {
  await loadCategories();
} catch (error) {
  console.error(error);
}
Thanks for any pointers…..
AI Update

This is indeed a JavaScript/TypeScript limitation when using sanity exec. The error occurs because you're using top-level await outside of an async function context.

The fix is straightforward: wrap your code in an async function. Here's your corrected script:

import { getCliClient } from 'sanity/cli';

const client = getCliClient().withConfig({ apiVersion: '2023-05-24' })

const loadCategories = async () => {
    const categories = await client.fetch('*[_type == "category"]');
    categories.forEach(category => {
        console.log(category)
    });
}

// Wrap in an async function
(async () => {
  try {
    await loadCategories();
  } catch (error) {
    console.error(error);
  }
})();

This creates an immediately-invoked async function expression (IIFE) that can use await internally. This is the standard pattern for migration scripts run with sanity exec.

Alternative: Use the migration tooling

If you're doing content migrations specifically, consider using Sanity's built-in migration tooling instead, which is the recommended approach. It provides several advantages:

  • Automatic batching of mutations to avoid rate limits
  • Dry-run mode by default with visual feedback
  • Better abstractions for document operations
  • Built-in validation against your schema

Create a migration script with:

npx sanity@latest migration create

The migration tooling is specifically designed for content transformations and handles many of the complexities automatically. However, sanity exec with the IIFE pattern works perfectly fine for simpler scripts or one-off operations!

Looks like wrapping in an IIFE helps

(async () => {
  await loadCategories();
})();

Sanity – Build the way you think, not the way your CMS thinks

Sanity is the developer-first content operating system that gives you complete control. Schema-as-code, GROQ queries, and real-time APIs mean no more workarounds or waiting for deployments. Free to start, scale as you grow.

Was this answer helpful?