What causes "`{typo}` may be a typo. Did you mean `{suggestion}`?" in oxc-project/oxc?

Rename the export to the exact suggested name with exact casing: `getStaticProps`, `getStaticPaths`, `getServerSideProps`, `getInitialProps`.

oxc-project/oxc · warning · OxcDiagnostic

`{typo}` may be a typo. Did you mean `{suggestion}`?

Error message

`{typo}` may be a typo. Did you mean `{suggestion}`?

What it means

Warning from oxlint rule `nextjs/no-typos`. Next.js opts pages into data fetching by exact export name (`getInitialProps`, `getStaticProps`, `getStaticPaths`, `getServerSideProps`, ...). A near-miss spelling silently opts the page out: it renders with no data and no build error. The rule uses edit-distance matching (`oxc_span::best_match`) to flag misspelled exports and suggest the intended name.

Source

Thrown at crates/oxc_linter/src/rules/nextjs/no_typos.rs:16

use oxc_ast::{
    AstKind,
    ast::{BindingPattern, Declaration},
};
use oxc_diagnostics::OxcDiagnostic;
use oxc_macros::declare_oxc_lint;
use oxc_span::{Span, best_match};

use crate::{
    AstNode,
    context::{ContextHost, LintContext},
    rule::Rule,
};

fn no_typos_diagnostic(typo: &str, suggestion: &str, span: Span) -> OxcDiagnostic {
    OxcDiagnostic::warn(format!("`{typo}` may be a typo. Did you mean `{suggestion}`?"))
        .with_help(format!("Change `{typo}` to `{suggestion}`"))
        .with_label(span)
}

#[derive(Debug, Default, Clone)]
pub struct NoTypos;

declare_oxc_lint!(
    /// ### What it does
    ///
    /// Detects common typos in Next.js data fetching function names.
    ///
    /// ### Why is this bad?
    ///
    /// Next.js will not call incorrectly named data fetching functions, causing pages to render without expected data.
    ///
    /// ### Examples
    ///

View on GitHub (pinned to a3d33dda7c)

Solutions

Rename the export to the exact suggested name with exact casing: `getStaticProps`, `getStaticPaths`, `getServerSideProps`, `getInitialProps`.
Add a type or unit check asserting page-level data-fetching exports are actually consumed, so unused exports surface early.

Example fix

// before
export async function getStaicProps() { /* never called by Next.js */ }

// after
export async function getStaticProps() { return { props: {} }; }

Defensive patterns

Strategy: type-guard

Validate before calling

const NEXT_FETCHERS = new Set([
  'getInitialProps', 'getStaticProps', 'getStaticPaths', 'getServerSideProps',
]);
// fail when a page exports something within typo distance but not exact:
for (const name of Object.keys(pageExports)) {
  if (!NEXT_FETCHERS.has(name) && /get/i.test(name)) console.warn('suspicious export:', name);
}

Type guard

function isNextDataFetcher(name: string): boolean {
  return new Set(['getInitialProps', 'getStaticProps', 'getStaticPaths', 'getServerSideProps']).has(name);
}

Prevention

Copy data-fetching names from the docs, casing included: getStaticProps, getStaticPaths, getServerSideProps.
Add a page test asserting the fetcher actually runs (props arrive), which a typo would fail.
Enable nextjs/no-typos in CI; it catches the near-miss before the page ships data-less.

When it happens

Trigger: An exported function whose name is within edit distance of a known Next.js data-fetching hook but not exactly equal — e.g. `getStaicProps`, `getServerSideProp`, or wrong casing such as `getinitialprops`.

Common situations: Typos neither TypeScript nor webpack catch (the export is simply unused); renames during refactors; mixing up singular/plural (`getStaticPath`).

Related errors

AI-assisted analysis of oxc-project/oxc@a3d33dda7c (2026-08-20). Data as JSON: /api/errors/a4815117a649f2d6. Report an issue: GitHub.