Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

CHEATSHEET.md and RFC 02 still recommend module-scope state for app-wide state (follow-up to #3390)

Open Beginner friendly
#4,141 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
1/5
Estimated time
1-3 hours
Newbie friendliness
86/100
Issue type
Documentation
Clarity
Clearly specified
Activity status
Active
Domain
documentation

Research direction

Read packages/solid/CHEATSHEET.md around line 353 and documentation/solid-2.0/02-signals-derived-ownership.md around line 93, then compare their guidance with the wording in the createContext JSDoc and the 2.0 state management guide. Update both outdated sentences to explain that providers own subtree and app-wide state, especially for SSR, and reserve module scope for constants. Done when both documents give consistent guidance.

Written by the indexing model from the issue text.

Description

Follow-up to #3390 / #3395, which fixed the createContext JSDoc. Two other copies of the same guidance were not updated and still say the opposite of the 2.0 docs (checked on next at d2ad8b28):

  • packages/solid/CHEATSHEET.md, line 353 ("Context, components, lazy"): "If you want truly app-wide state, don't use Context — a module-scope signal/store is a global."
  • documentation/solid-2.0/02-signals-derived-ownership.md, line 93: the same sentence.

The cheatsheet copy matters most, because it is the one written for AI tools:

  • It ships in the package (node_modules/solid-js/CHEATSHEET.md, 2.0.0-rc.15 included).
  • The README's "For LLMs / AI assistants" section and the new solid-2.0 primer skill both point agents to it.
  • scripts/build-cheatsheet-skill.mjs publishes it as the solid-2.0-cheatsheet skill.

So agents that follow Solid's own guidance learn the rule the docs reversed on 2026-09-07 (solid-docs 413890c, "recommend context over module state"). Concepts → Reactivity, Components and JSX → Context, and the State management guide all say to prefer a provider, and to use module scope only for constants and the createContext call.

Suggested fix: replace both sentences with the wording #3395 put in the JSDoc:

Context is for state that belongs to a subtree, which includes app-wide state in an app that renders on the server: a value created inside a component is created once per request, and the Provider owns and disposes it. Module scope is shared by every request in the same process, so reserve it for constants.

Optionally, add the client-only nuance from the State management guide: without ssr: true, a module-scope store is one store per tab, but it becomes shared server state the day SSR is turned on, so creating it in a provider from the start is the portable choice.

Dominant language
TypeScript
Stars
36.1k
Forks
1.1k
Avg merge
11h 45m
Merged PRs (30d)
329

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from solidjs/solid

All issues in solidjs/solid

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.