oxc-project/oxc · warning · OxcDiagnostic

Missing return type on function.

Error message

Missing return type on function.

What it means

typescript/explicit-function-return-type reports function-like nodes whose return_type is None. Defaults: allowTypedFunctionExpressions, allowHigherOrderFunctions, and allowDirectConstAssertionInArrowFunctions are true, while allowExpressions and allowIIFEs are false, so unannotated function declarations, methods, and immediately-invoked functions are the main targets. It forces the author to state the output contract explicitly.

Source

Thrown at crates/oxc_linter/src/rules/typescript/explicit_function_return_type.rs:143

    /// var arrowFn = (): string => 'test'
    ///
    /// class Test {
    ///     // No return value should be expected (void)
    ///     method(): void {
    ///         return
    ///     }
    /// }
    /// ```
    ExplicitFunctionReturnType,
    typescript,
    restriction,
    config = ExplicitFunctionReturnTypeConfig,
    version = "0.4.4",
    short_description = "This rule enforces that functions have an explicit return type annotation.",
);

fn explicit_function_return_type_diagnostic(span: Span) -> OxcDiagnostic {
    OxcDiagnostic::warn("Missing return type on function.")
        // TODO: actually provide a helpful message.
        .with_help("Require explicit return types on functions and class methods.")
        .with_label(span)
}

impl Rule for ExplicitFunctionReturnType {
    fn from_configuration(value: serde_json::Value) -> Result<Self, serde_json::error::Error> {
        DefaultRuleConfig::<Self>::from_value(value).map(DefaultRuleConfig::into_inner)
    }

    fn run<'a>(&self, node: &AstNode<'a>, ctx: &LintContext<'a>) {
        match node.kind() {
            AstKind::Function(func) => {
                if !func.is_declaration() && !func.is_expression() {
                    return;
                }

                if func.return_type.is_some() || is_constructor_or_setter(node, ctx) {

View on GitHub (pinned to e1e7af627c)

Solutions

1. Add the return type: `function f(): void {}`, `const f = (): number => 1`, `method(): string { ... }`
2. Set "allowExpressions": true to exempt function expressions passed as arguments or assigned to variables
3. Set "allowIIFEs": true if immediately-invoked functions should be exempt
4. If the policy is too strict, replace this rule with typescript/explicit-module-boundary-types which only checks the exported surface

Example fix

// before
function add(a: number, b: number) {
  return a + b;
}

// after
function add(a: number, b: number): number {
  return a + b;
}

// .oxlintrc.json — scope the rule to what the team actually wants
{
  "rules": {
    "typescript/explicit-function-return-type": [
      "warn",
      {
        "allowExpressions": true,
        "allowIIFEs": true,
        "allowTypedFunctionExpressions": true,
        "allowHigherOrderFunctions": true,
        "allowDirectConstAssertionInArrowFunctions": true
      }
    ]
  }
}

When it happens

Trigger: `function f() {}`, `const f = () => 1;`, class methods without return annotations, or `(function () {})()` with allowIIFEs left false; the node is only exempt if it matches one of the allow* conditions (e.g. a typed function expression or a directly returned arrow with `as const`).

Common situations: Turning the rule on mid-project and getting hundreds of reports; arrow functions assigned to untyped consts; callbacks flagged because allowExpressions is false; teams wanting return types only on public APIs (explicit-module-boundary-types) rather than everywhere.

Related errors

• Missing return type on function
• Missing argument type on function
• encountered allocation error
• Do not use @ts-{ts_comment_name} because it alters compilati
• Use "@ts-expect-error" instead of @ts-ignore, as "@ts-ignore

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