{"record":{"id":"f68b0c80f7d84f6a","repo":"oxc-project/oxc","slug":"do-not-access-a-member-directly-from-an-await-expr","errorCode":null,"errorMessage":"Do not access a member directly from an await expression.","messagePattern":"Do not access a member directly from an await expression\\.","errorType":"validation","errorClass":"OxcDiagnostic","httpStatus":null,"severity":"warning","filePath":"crates/oxc_linter/src/rules/unicorn/no_await_expression_member.rs","lineNumber":12,"sourceCode":"use oxc_ast::{\n    AstKind, MemberExpressionKind,\n    ast::{BindingPattern, Expression},\n};\nuse oxc_diagnostics::OxcDiagnostic;\nuse oxc_macros::declare_oxc_lint;\nuse oxc_span::{GetSpan, Span};\n\nuse crate::{AstNode, context::LintContext, rule::Rule};\n\nfn no_await_expression_member_diagnostic(span: Span) -> OxcDiagnostic {\n    OxcDiagnostic::warn(\"Do not access a member directly from an await expression.\")\n        .with_help(\"Assign the result of the await expression to a variable, then access the member from that variable.\")\n        .with_label(span)\n}\n\n#[derive(Debug, Default, Clone)]\npub struct NoAwaitExpressionMember;\n\ndeclare_oxc_lint!(\n    /// ### What it does\n    ///\n    /// Disallows member access from `await` expressions.\n    ///\n    /// ### Why is this bad?\n    ///\n    /// When accessing a member from an `await` expression,\n    /// the `await` expression has to be parenthesized, which is not readable.\n    ///\n    /// ### Examples","sourceCodeStart":1,"sourceCodeEnd":30,"githubUrl":"https://github.com/oxc-project/oxc/blob/e1e7af627c8843ab64044ed466b128fcc21a035b/crates/oxc_linter/src/rules/unicorn/no_await_expression_member.rs#L1-L30","documentation":"Diagnostic from the oxlint rule `unicorn/no-await-expression-member` (crates/oxc_linter/src/rules/unicorn/no_await_expression_member.rs). It fires when a property is accessed directly on an `await` expression, such as `(await getUser()).name`. The code runs correctly at runtime; the rule is stylistic: reading members off an inline await is easy to misread and hard to extend, so it asks you to bind the awaited result to a variable first.","triggerScenarios":"Any static or computed member access whose object is an AwaitExpression: `(await loadConfig()).retries`, `console.log((await getStats()).total)`, `(await readBlock())[0]`. The flagged shape is `(await x).y`, not the chained call `await x.y()`.","commonSituations":"One-off field reads in async functions; developers inlining awaits to save a line; teams enabling oxlint's unicorn preset (or raising lint severity from warn to error in CI) and hitting style failures on existing code.","solutions":["Assign the awaited value first, then access the member: `const user = await getUser(); user.name`","If the inline form is deliberate, suppress once with `// oxlint-disable-next-line unicorn/no-await-expression-member`","If the team prefers inline awaits overall, turn the rule off in the rules section of .oxlintrc.json"],"exampleFix":"// before\nconsole.log((await getUser()).name);\n\n// after\nconst user = await getUser();\nconsole.log(user.name);","handlingStrategy":"validation","validationCode":null,"typeGuard":null,"tryCatchPattern":null,"preventionTips":["In async code, always bind `const x = await p` before touching x's members","Run oxlint in the editor (VS Code extension) so this fires on save, not in CI","Keep newly adopted style rules at warn level until the codebase is cleaned up"],"tags":["async-await","style","readability","oxlint"],"backgroundTag":"await-expression-member-access","analyzedSha":"e1e7af627c8843ab64044ed466b128fcc21a035b","analyzedAt":"2026-08-20T07:01:07.079Z","contentChangedAt":"2026-08-20T07:01:07.079Z","schemaVersion":2},"datasetVersion":"2026-09-14T05:17:10.506Z"}