oxc-project/oxc · warning · OxcDiagnostic
Missing argument type on function
Error message
Missing argument type on function
What it means
Argument-side diagnostic of typescript/explicit-module-boundary-types: parameters of exported functions and public class members must carry explicit type annotations. Implicit any at a boundary hides the input contract from consumers and defeats the point of the rule. The same allowedNames/allow* exemptions apply as for the return-type variant.
Source
Thrown at crates/oxc_linter/src/rules/typescript/explicit_module_boundary_types.rs:33
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)
}
#[derive(Debug, Default, Clone, Deserialize)]
pub struct ExplicitModuleBoundaryTypes(Box<ExplicitModuleBoundaryTypesConfig>);
impl Deref for ExplicitModuleBoundaryTypes {
type Target = ExplicitModuleBoundaryTypesConfig;
View on GitHub (pinned to e1e7af627c)
Solutions
- Annotate each parameter: `export function parse(input: string) { ... }`
- When the shape is genuinely unknown, use `unknown` and narrow inside the function instead of leaving it implicit
- Exempt specific names via "allowedNames" if a function cannot be annotated yet
Example fix
// before
export function greet(name) {
return `hello ${name}`;
}
// after
export function greet(name: string): string {
return `hello ${name}`;
} Defensive patterns
Strategy: validation
Validate before calling
// .oxlintrc.json
{
"rules": {
"typescript/explicit-module-boundary-types": [
"warn", { "allowArgumentsExplicitlyTypedAsAny": false }
]
}
}
// tsconfig.json — let the compiler catch implicit any too
{ "compilerOptions": { "noImplicitAny": true } } Prevention
- Enable noImplicitAny so untyped boundary parameters fail compilation, not just lint
- Write exported function signatures top-down (parameters first) so annotation is the default habit
- For dynamic payloads, define request/response interfaces at the edge instead of relying on inference
When it happens
Trigger: `export function parse(input) { ... }` or a public method with an untyped parameter on an exported class; destructured or rest parameters without annotations are also flagged; constructors are treated as implementation details and set-accessors are skipped by the checker.
Common situations: Migrating a JS module to TS one function at a time; default parameters relying on inference (`export const f = (n = 1) => n`); callbacks exported without parameter types.
Related errors
- Missing return type on function.
- Missing return 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/b52edf6c6ece0547.
Report an issue: GitHub.