TheOdinProject/theodinproject: the application, not the lessons

The lesson text lives in another repository

This repository is the application, not the curriculum. It pulls lesson content and holds the front end and back end code, while the lesson text itself sits in the TOP curriculum repository, which is where the README sends anyone who wants to see the actual content. That split explains a lot of what a newcomer finds on the first visit: the topic list covers Ruby, Ruby on Rails, SQL, HTML and CSS, Javascript, Node and React, and how to go about getting a job in the industry, yet none of those lessons are in this tree. Two destinations are named for everything outside the code: the TOP Discord server for the community and CONTRIBUTING.md for anyone who wants to change the curriculum, with the README welcoming contributors of all experience levels and backgrounds.

Two build commands, one for JavaScript and one for CSS

The asset pipeline is split across two commands, and neither is a bundler default. The build script runs node esbuild.config.mjs, so JavaScript bundling is driven by a standalone esbuild config file at the repository root. The build:css script shells out through npx to the Tailwind CLI, reading app/assets/stylesheets/application.tailwind.css and writing app/assets/builds/application.css. Tailwind is pinned at 4.3.3 and arrives as three packages, the CLI plus the forms and typography plugins, with tailwind.config.js at the root as the matching config file. Linting has two entries too, one JavaScript and one stylesheet, and the stylesheet one takes a directory argument rather than a glob.

  "scripts": {
    "lint": "standard",
    "stylelint": "stylelint 'app/assets/stylesheets'",
    "build": "node esbuild.config.mjs",
    "build:css": "npx @tailwindcss/cli -i ./app/assets/stylesheets/application.tailwind.css -o ./app/assets/builds/application.css"
  },

Yarn 4 travels with the tree, and the package is private

The packageManager field pins [email protected], and the repository checks in a .yarn directory next to .yarnrc.yml, so the Yarn version is decided by the tree rather than by whatever happens to be installed globally. Two ecosystems are pinned side by side: yarn.lock for JavaScript, Gemfile and Gemfile.lock for Ruby, plus .ruby-version and .node-version for the runtimes themselves, and a vendor directory. That is four files to keep in step whenever a dependency moves, and a contributor who updates one lock file without the others can end up with a tree the project never tested. The package is marked private at version 1.0.0, so the version field tracks the application rather than a library that anyone installs from a registry.

The Ruby side has lint config but no matching script

JavaScript linting is wired into the npm scripts, while the Ruby and template tooling is configured only through dotfiles at the top level. .rubocop.yml, .erb_lint.yml and .better-html.yml describe the Ruby, ERB template and static markup checks, and .rspec is present for the test runner alongside a spec directory. The application layout is the usual one for a Rails service: app/, config/, db/, lib/, public/, bin/, script/, a Rakefile and config.ru at the root, and the dependency list carries the Rails front end pairing of @hotwired/stimulus with @hotwired/turbo-rails and @rails/request.js. The README does not say which command runs the Ruby linters, so that entry point has to be found in the tooling itself.

What a lesson page needs in the browser

The dependency list describes the reading experience rather than a framework. prismjs handles code highlighting and esbuild-plugin-prismjs connects it to the bundler, mermaid covers diagrams, chart.js with chartjs-plugin-crosshair draws charts that need a crosshair, sortablejs handles reordering, flatpickr handles date and time input, and tippy.js with el-transition covers tooltips and animation. @sentry/browser reports errors from the page and @sentry/esbuild-plugin connects the same service to the build. Stimulus controllers and stimulus-use provide the behavior layer on top of Turbo. Two names in the list, chokidar and debounce, are not referenced by any of the four scripts, so package.json alone does not show what uses them.

Three process files and a sample environment

Startup is described by more than one file. Procfile and Procfile.dev sit at the root, .foreman sits beside them, and config.ru and bin/ provide the entry points, which leaves room for the local process list to differ from the deployed one. Environment variables are represented by env.sample rather than a committed secrets file. The README documents none of this: it does not name the Ruby or Node version beyond the version files, does not identify a database, and does not give a single command that starts the site. A newcomer who follows the README alone ends up with the curriculum links and nothing about running the application, which is the gap this repository leaves for its own setup documentation to fill.

Two agent instruction files sit beside the contributing guide

AGENTS.md and CLAUDE.md are both present at the top level, next to CONTRIBUTING.md. Only the contributing guide is announced in the README, and it is presented as the document to read before contributing to the curriculum. The other two have no description anywhere in the README, so whether they carry setup commands, code conventions or something else cannot be told from this repository alone. Their presence does mean there are now three places where instructions can be written for anyone working here, and a contributor who finds only the contributing guide may follow rules that the agent files contradict or repeat.

No releases, and two slug files nobody explains

The default branch is main, the last push was on 2026-11-02, and the repository has no GitHub releases, so there is no tagged version to pin and no changelog to read: the deployable unit is the tip of main. Two configuration files, .slugignore and .slugcleanup, are checked in without any mention of what consumes them, alongside .gitattributes, .gitignore, app.json, a log directory and a tmp directory. Licensing is consistent on the surface, with license.txt at the root and MIT declared inside package.json, matching the MIT license GitHub reports for the repository. app.json is a second declaration file in the root, and this repository never says what reads it or whether a deploy depends on it at all.

Editorial conclusion

Read it as the web layer of a curriculum rather than as a course: the lessons themselves live in the curriculum repo, and nothing here is packaged for installation. Before you plan work against it, confirm the Ruby and Node versions in .ruby-version and .node-version, find out which process file the current workflow uses, and remember there is no release tag, so any pin you write has to be a commit on main.

Frequently asked questions

Official sources

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