javascripting turns a JavaScript tutorial into a set of files you edit until the tests pass

An adventure loop rather than a lesson list

The README is short and the whole product fits in it. You install the package globally, you run one command, and a menu appears:

npm install -g javascripting

javascripting

You navigate the menu with the up and down arrow keys and choose a challenge with enter. Each challenge opens a file, you edit it, and something grades your edit. That grading step is the whole design, and it comes from a separate package rather than from code in this repository: `package.json` lists `workshopper-adventure` at `^7.0.0` as a runtime dependency, alongside `colors` for terminal output and `diff` for showing what changed.

`diff` being a hard dependency tells you what the feedback loop looks like in practice. This is not a tutorial that prints an error message and leaves you to work out the rest. It compares your attempt against a reference and shows you the difference, which for a learner is a much more useful signal than a stack trace from an assertion.

The repository is built to be read. The tree contains `problems/` for the exercises, `solutions/` for the answers, `menu.json` for what the menu renders, `bin/` for the entry point, `lib/` for the logic and `i18n/` for translations. Both directories present means you can read a problem and its answer side by side, which is either the fastest way in or the fastest way to spoil it.

The test suite is the grading mechanism, and standard is the lint

The `test` script in `package.json` is the clearest statement of how the project checks itself, and it is two commands:

  "scripts": {
    "test": "standard && workshopper-adventure-test"
  }

`standard` is a JavaScript style linter with no configuration file, run here across the repository. `workshopper-adventure-test` comes from a separate `workshopper-adventure-test` dev dependency and is what validates the workshop itself. The `.workshopper-test.config.js` file at the root is where that second command gets its settings, which suggests the configuration is thin rather than elaborate.

The same shape applies to the learner's work. A participant is not asked to run a test command by hand and interpret output; the workshop does it, and `diff` renders the comparison. The tradeoff is that the exercises have to stay small enough to grade automatically. That is a real design constraint on the content, and it explains why this covers language fundamentals rather than, say, how to structure an application.

It also explains the honest limitation. A grader can check that a function returns a particular value for particular inputs. It cannot tell you that your solution is readable, and it will happily accept a hardcoded lookup table. Nothing in the setup pushes back on that, so the pedagogical ceiling is whatever the exercise author decided to check.

A Node floor of 22, and what that rules out

The `engines` field in `package.json` asks for `node >=22`. That is a sharp constraint for a tutorial aimed at people new to JavaScript, and it is worth being blunt about the effect: a reader on an older long-term-support release of Node cannot install this at all without upgrading first, or without ignoring the engine check.

Everything else in the manifest points the same way, toward a project being kept current rather than left as-is. The published version is 2.7.4. The `diff` dependency is at `^9.0.0`, `standard` at `^17.1.2`, both recent majors, and `preferGlobal` is set to true, which is what makes the global install the intended path rather than a shortcut. The README even tells you to install Node.js from nodejs.org before anything else and to make sure it is installed, a step that would be unnecessary if a broad range of versions were fine.

Two documents in the tree tell you the project expects real friction from users. There is a `TROUBLESHOOTING.md` that the README links from a help section, and a `LOCALIZING.md` for translations. The localization file sits next to `i18n/`, so the workshop is designed to be translated, and that is the sort of care that rarely shows up in a repository otherwise built around a single idea.

GitHub reports the last push on 2026-09-02, so the repository is being touched, but it publishes no GitHub releases at all. There is no changelog and no version history to read, which means `2.7.4` in the manifest is the only version information available to you.

One editor recommendation, and the advice around it

The README's advice on editing is where the document shows its age most clearly, which is useful to a reader calibrating how much to trust the rest of it. It walks through the first challenge using a recorded demo, and says the command line editor used there is `nano`, linking to a page of basic `nano` usage tips. It then says you can use any editor you like, and names two graphical options as good ones.

Those two named editors are the part to set aside. Neither is what a current JavaScript learner would be told to reach for, and the advice predates the current state of the JavaScript tooling ecosystem. The `nano` suggestion is more defensible, since learning a modal editor's basics is a real skill and the linked tips would get a newcomer through the exercise.

The broader point survives the dated examples: this workshop runs inside a terminal and hands you a file path. Anything that edits a file works, whether that is a terminal editor, a full IDE, or an agent writing the change for you. Nothing about the exercise requires a particular editor, and the README is right to say so.

There is one genuine advantage to staying in the terminal that the README does not argue for. There is no browser, no bundler and no dev server to start, so the feedback loop is a single command you already know. For a first exercise, that is worth more than it sounds.

Where help comes from when an exercise defeats you

The README routes support to three places: a shared discussions repository for the NodeSchool workshops, a Gitter channel, and the repository's own issues. It also points at `TROUBLESHOOTING.md` as the place to start.

For help on a specific exercise, it gives a concrete convention that is worth following if you do open an issue: include the name `javascripting` and the name of the challenge you are working on in the title. That sounds fussy and is exactly right, because it means someone triaging can route the report without reading the body.

The shared discussions repository is the more interesting of the destinations. This workshop is one entry in a family, with nodeschool.io as the project's declared homepage and the README describing it as a place to find more interactive tutorials of the same kind. That framing matters for how you judge the project. javascripting is not trying to be a complete JavaScript course; it is one workshop in a collection with a shared support channel and a common shape, where each is a menu, a set of files, and a grader.

Contributions are invited through `CONTRIBUTING.md`, and the `LICENSE.md` plus the MIT declaration in `package.json` settle the licensing question plainly.

The workshop is a config file and a directory of problems, not an application

It is worth being concrete about how little code is involved. `menu.json` describes what the arrow-key menu offers, `problems/` holds the exercises, `solutions/` holds the answers, and `index.js` with the `lib/` directory is the logic that ties them together. The `bin` field points the global install at `./bin/javascripting`, so that script is what your shell actually runs.

That structure is a direct consequence of building on `workshopper-adventure` rather than writing a terminal framework. The menu, the file opening, the grading and the diff rendering all come from the dependency. What this repository supplies is content, configuration and the wiring.

It also makes writing a new workshop a data exercise rather than a programming one, which is why `workshopper-adventure-test` and the `.workshopper-test.config.js` file exist: there is a checker for the workshop format itself. If you want a workshop for a language or topic nobody has covered, the pieces to copy are here and the framework to copy them onto is already a dependency.

One practical warning follows from `solutions/` shipping in the tree. Do not clone this repository to take the exercises. Install the published package instead, which is what `preferGlobal` in `package.json` is set up for, and the answers will not be sitting in your working directory.

Editorial conclusion

javascripting is at its best as a supervised or self-paced first pass through JavaScript syntax, because its exercises are small, its feedback is a diff, and it never asks you to leave the terminal. Its limits are the limits of the format: no runtime visual feedback, no project structure, and a Node requirement of 22 or newer that puts a floor under who can install it. It also publishes no GitHub releases, so the version in `package.json`, 2.7.4, is the only place to check what you have. If you want the same drill-based shape with a browser or a debugger attached, look to the other NodeSchool workshops listed on nodeschool.io instead, and read `TROUBLESHOOTING.md` before your first session.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. workshopper/javascripting on GitHub