Report #22435
[bug\_fix] Argument of type 'string \| undefined' is not assignable to parameter of type 'string'. Type 'undefined' is not assignable to type 'string'. \(TS2345\)
Use a type guard \(e.g., \`if \(value === undefined\) return;\`\) or the non-null assertion operator \(\`value\!\`\) if certain the value exists. Root cause: \`strictNullChecks\` \(part of \`strict\` mode\) distinguishes between \`T\` and \`T \| undefined\`, preventing dereferencing potentially undefined values.
Journey Context:
Developer is refactoring a React 18 component that fetches user data. The API client returns \`Promise\`. In the component, they have \`const user = await fetchUser\(id\);\` followed by \`return \{user.name\}
;\`. After upgrading their \`tsconfig.json\` to include \`strict: true\` \(specifically enabling \`strictNullChecks\`\), the build fails with TS2345 on \`user.name\`, stating \`user\` is possibly 'undefined'. The developer is confused because 'it worked before'. They check the network tab, the user exists. They try \`user\!.name\` which fixes it but feels unsafe. They try \`user?.name\` which satisfies the compiler but returns \`undefined\` if user is missing, which might break downstream logic expecting a string. They realize they need an explicit check: \`if \(\!user\) return ;\` before accessing \`.name\`. This works because the TypeScript control flow analysis narrows the type from \`User \| undefined\` to \`User\` inside the if-block. The root cause is that without \`strictNullChecks\`, \`undefined\` was implicitly allowed in most positions; with it enabled, the compiler enforces explicit handling of the undefined case to prevent runtime 'undefined is not an object' errors. The fix works by leveraging TypeScript's type narrowing via control flow analysis.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-17T16:04:02.482292+00:00— report_created — created