wordplaydev/wordplay: an educational language whose package and release versions disagree

The package version and the release tags do not agree

Two version lines exist and they do not line up. package.json records the project at 0.38.1, while the recent GitHub releases are v0.6.37, tagged as A bit of polish on 2025-12-14, v0.6.36, tagged as Wordplay 0.6.36: Maintenance on 2025-12-07, and v0.12.0 from 2024-09-22. Read the release list in order and the numbering looks wrong in a second way, since 0.6.37 and 0.6.36 sit above a 0.12.0 even though they were published more recently. The last push to main is dated 2026-09-28, which is newer than any tag, so the tag list is not a reliable picture of current state either. If you need to cite a version of Wordplay, cite the commit, not the tag.

postinstall runs six setup steps before you see anything

Installing dependencies triggers a chain of setup work, not just a package download. The postinstall script is `run-script-os`, which picks between two platform variants, and the default variant chains svelte-kit sync, a copy of .env.template to .env, locales-assemble, updates, locale-assets, fonts-build and git-config. The Windows variant is the same chain with `copy` in place of `cp`. Two details are worth knowing before your first install. The environment file is generated for you from the template, with .env.demo-wordplay also present at the top level. And the last step, git-config, runs `npx tsx scripts/setup-git-config.ts`, so the install writes to your git configuration as a side effect rather than only touching the project directory.

Tests come in four projects, and the rules suite needs Firestore

The test surface is tiered rather than flat. The default test script runs vitest across the fast and isolated projects, test:run does the same without watch mode, test:sweep runs the sweep project, test:all runs everything, and test:coverage adds instrumentation. The interesting split is test:rules, which does not run vitest directly: it wraps the run in `firebase emulators:exec --only firestore` against vitest.rules.config.ts. In other words the security rules are tested against an emulated Firestore, not a stub. The end-to-end scripts follow the same pattern, each invoking firebase emulators:exec around a Playwright run scoped to the demo-wordplay project, with variants for a quick pass, a changed-files-only run using --only-changed, and a rerun of the last failures using --last-failed.

Firestore is the backend, and the rules have their own suite

The persistence layer is Firebase, and it is configured in the repository rather than assumed. At the top level sit firebase.json, .firebaserc, firestore.rules and firestore.indexes.json, alongside a functions/ directory for server-side code and migration_scripts/ for schema and data moves. Two things follow from that layout. Access control lives in firestore.rules, which is why a dedicated rules test project exists and why it needs the emulator rather than a mock: rules are the contract between the browser client and the database. And indexes are declared in their own file, so a query that outgrows a single-field index is a committed change rather than something discovered in production.

The top level is a working repository, not a package

What sits at the root tells you how the project is worked on. There are editor and agent configuration directories in .claude/, .nova/ and .vscode/, a .mcp.json, a .githooks/ directory, ARCHITECTURE.md, CLAUDE.md, CONTRIBUTING.md, EMAILS.md and RECOVERY.md, and a CHANGELOG.md. Alongside those are files that look like output rather than source: diff_output.txt and ui-debug.log are both committed, alongside test-time.mjs and .share-tabs.mjs as loose scripts. The build stack is SvelteKit with Vite, so you get svelte.config.js, vite.config.js and a tsconfig.json, plus two Playwright configurations, playwright.config.ts and playwright.contactsheet.config.ts, and a .nvmrc pinning the Node version for everyone who clones.

Formatting is enforced and hidden from blame afterwards

Prettier is wired into the scripts rather than left to individual discipline. `format` writes with prettier --write ., `format:check` verifies with prettier --check ., and the configuration sits in .prettierrc.json with an ignore list in .prettierignore. Type checking is separate and stricter: the check script runs svelte-check against ./tsconfig.json with --fail-on-warnings, and check:now runs the same thing without the watch flag. A .git-blame-ignore-revs file sits at the root, which tells you whole-tree reformats happen often enough that the project hides those commits from blame. That is the pattern to expect if you contribute: run the formatter, keep the reformat in its own commit, and register it.

The README points at the site, not at the code

The README is deliberately short, and what it contains is a set of destinations. It describes Wordplay as a web-based programming language, IDE and platform for creating accessible, interactive typography, designed, built and evolved with youth and teachers and facilitated by Amy J. Ko at the University of Washington. Then it sends you three places: wordplay.dev for the about page and the tutorial, the contributor guide in the project wiki, and LANGUAGE.md in the repository for the always evolving language specification. So the split is clear. The repository holds the application, the Firebase backend and the language specification; the teaching material lives on the site; and the process lives in the wiki. Reading ARCHITECTURE.md and CONTRIBUTING.md in the repository is the next step after the tutorial.

Editorial conclusion

Wordplay suits a classroom or a curious learner who wants to make type behave, and the honest way to approach it is through the website rather than the repository, since the tutorial and the about page are where the project actually explains itself. Before you clone, expect a heavier setup than a typical SvelteKit app: the postinstall chain assembles locales, fonts and git config, and the rule and end-to-end suites need the Firestore emulator running. Also do not trust either version number on its own, because package.json and the release tags disagree.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes