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
- Annotate the exported signature: `export function parse(input: string): Result { ... }`
- Add names of functions that should keep inferred returns to "allowedNames"
- Set "allowOverloadFunctions": true when using overload signature groups
- 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
- Prefer this rule over explicit-function-return-type for libraries; internals stay inference-friendly
- Annotate exported signatures as you write them — retrofitting on a big surface is expensive
- Pair with API extractor or tsc --declaration so the annotations are what consumers actually see
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
- 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/c4c24276dda501bd.
Report an issue: GitHub.