You know the pattern: createContext<User | null>(null), then a useAuth() hook that throws "useAuth must be used within AuthProvider", and every consumer either trusts that or null-checks. A missing provider is a runtime error you find when that screen renders, or when a test does.

I wanted it to be a lint error instead, so I built an oxlint plugin that checks it across the whole program:

``` const AuthContext = createContext<User | null>(null);

function Children() { const user = use(AuthContext); return <p>{user?.name}</p>; }

root.render( <AuthContext value={user}> <Children /> {/* ok */} </AuthContext>, );

root.render(<Children />); // <sup>^</sup> react-context(require-provider): <Children> needs AuthContext // (use(AuthContext) at Children.tsx:4), but no <AuthContext> provider is above it. ```

Children needs no annotations. Requirements are inferred from use, useContext, <Ctx.Consumer> and static contextType. They're passed up through components, custom hooks, HOCs, memo/forwardRef/lazy, children and render props, and React Router outlets, until a provider meets them or a root gets them. Roots are createRoot().render, testing-library's render, Storybook stories, and framework pages you list in a setting. Wrapper components like <AuthProvider>{children}</AuthProvider> count as providers because they render children inside one.

There's also a tiny optional runtime: createRequiredContext<User>() gives you a context where use() is typed User instead of User | null, because the lint rule now guarantees the provider. It returns a plain React context, so nothing else changes.

Why not types? That was the first thing I tried. JSX erases element types: <Children /> and <span /> are both just JSX.Element, so a requirement can't travel from a child up to its provider through the type system. Forking @types/react doesn't help, and TypeScript 7.1's new APIs didn't open a way either. The only version that type-checked used generator components and h() calls instead of JSX, which nobody wants.

As for the speed, it's a whole program so it costs more than a normal lint rule. On excalidraw (709 files), oxlint alone takes 0.07 s, oxlint with the rule 0.8 s, and the standalone CLI 0.5 s. In the editor (oxlint's language server), a keystroke costs about 50 ms because only the edited file is re-parsed. The README suggests a separate oxlint config so that your everyday oxlint stays as fast as before, while the editor uses the config with the rule and CI runs react-context-check as its own step. Not on oxlint? The CLI runs the same check without it.

As for limitations, it's syntactic and not type-aware. For code it can't see (node_modules, dynamic tags, useContext(cond ? A : B)) it makes certain assumptions. A provider hidden in such code shows up as a false positive, which you silence with @context-provided. A null-default context that your code actually treats as optional needs a // @context-optional comment. On excalidraw, that one comment was the difference between 337 reports and zero.

It's not on npm yet:

npm i -D github:TmLev/react-context-typesafe oxlint

Repo: https://github.com/TmLev/react-context-typesafe

Reports of wrong diagnostics are the most useful feedback right now. A few lines of code that reproduce one are enough.