oxc-project/oxc · warning · OxcDiagnostic

Missing return type on function

Error message

Missing return type on function

What it means

typescript/explicit-module-boundary-types requires return type annotations on exported functions and on public members of exported classes, unlike explicit-function-return-type it checks only the module's public surface. Defaults: allowTypedFunctionExpressions, allowHigherOrderFunctions, and allowDirectConstAssertionInArrowFunctions are true; allowedNames and allowOverloadFunctions (false) provide narrower exemptions.

Source

Thrown at crates/oxc_linter/src/rules/typescript/explicit_module_boundary_types.rs:27

use oxc_diagnostics::OxcDiagnostic;
use oxc_macros::declare_oxc_lint;
use oxc_semantic::ScopeFlags;
use oxc_span::GetSpan;
use oxc_str::CompactStr;
use rustc_hash::{FxHashMap, FxHashSet};
use schemars::JsonSchema;
use serde::Deserialize;
use serde_json::Value;
use smallvec::SmallVec;

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

fn func_missing_return_type(fn_span: Span) -> OxcDiagnostic {
    OxcDiagnostic::warn("Missing return type on function")
        .with_help("Define an explicit return type for the function.")
        .with_label(fn_span)
}

fn func_missing_argument_type(param_span: Span) -> OxcDiagnostic {
    OxcDiagnostic::warn("Missing argument type on function")
        .with_help("Define an explicit argument type for each argument.")
        .with_label(param_span)
}

fn func_argument_is_explicitly_any(param_span: Span) -> OxcDiagnostic {
    OxcDiagnostic::warn("Argument is explicitly typed as `any`")
        .with_help(
            "Avoid explicit `any` at module boundaries; prefer `unknown` and narrow before use.",
        )
        .with_label(param_span)
}

View on GitHub (pinned to e1e7af627c)

Solutions

  1. Annotate the exported signature: `export function parse(input: string): Result { ... }`
  2. Add names of functions that should keep inferred returns to "allowedNames"
  3. Set "allowOverloadFunctions": true when using overload signature groups
  4. Prefer this rule over explicit-function-return-type when you only care about the module boundary, and disable the broader one

Example fix

// before
export function format(input: string) {
  return input.trim();
}

// after
export function format(input: string): string {
  return input.trim();
}
Defensive patterns

Strategy: validation

Validate before calling

// .oxlintrc.json — check only the exported surface
{
  "rules": {
    "typescript/explicit-module-boundary-types": [
      "warn",
      { "allowedNames": [], "allowOverloadFunctions": true }
    ]
  }
}

Prevention

When it happens

Trigger: `export function f(x: string) { ... }` with no return annotation, or a public method on an exported class without one, where the name is not in allowedNames and no allow* exemption applies; overload signature sets are reported unless allowOverloadFunctions is enabled.

Common situations: Library authors wanting typed public APIs without annotating every internal function; enabling both this and explicit-function-return-type and getting duplicate pressure; overloads written for option objects being flagged.

Related errors


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