curriculum Documentation

The open curriculum for learning web development

12,884 stars JavaScript JavaScript 1 file · ~6,578 tokens #css#curriculum#html#javascript#lessons#node#nodejs#ruby
RAW Doc

File: README.md

The Odin Project Curriculum

The Odin Project (TOP) is an open-source curriculum for learning full-stack web development. Our curriculum is divided into distinct courses, each covering the subject language in depth. Each course contains a listing of lessons interspersed with multiple projects. These projects give users the opportunity to practice what they are learning, thereby reinforcing and solidifying the theoretical knowledge learned in the lessons. Completed projects may then be included in the user's portfolio.

Lessons are structured through a combination of original written content and a compilation of carefully curated resources from the web. This is where the contributing happens!

This repo contains the actual lesson files used on our website. For the actual TOP app that pulls in this lesson content and contains our front-end and back-end code, please go to the main TOP repo.

Our community can be found on the TOP Discord server.

Contributing

The Odin Project depends on open-source contributions to improve, grow, and thrive. We welcome contributors of all experience levels and backgrounds to help maintain this awesome curriculum and community. If you would like to contribute to our curriculum, be sure to thoroughly read our contributing guide.

Some of the things you can do to contribute to our curriculum include:

  • Correct typos and other grammar errors.
  • Rewrite parts of existing lessons to make them clearer and easier to understand.
  • Fix broken links.
  • Add new resource links you think would make a lesson better.
  • Work on entirely new lessons after getting approval.

Happy Coding!

See license.md for usage details.

Created by Erik Trautman.

File: archive/html_css/README.md

Good web design doesn't happen by accident. This course takes a deeper look at front-end design and development, expanding on what is covered in Foundations. You'll learn how to design and develop websites that look great in any device and you'll be equipped to deeply understand and create your own responsive design framework!

The Outline

File: archive/old_lessons/foundations/JS101/README.md

This is the beginning of the JS curriculum!!

How I envision it playing out: Stub out the lessons for each section (like I've done here) with simple descriptions of the content and then go through and start filling them out.

This is almost definitely going to change... things are likely to be moved quite a lot once we start actually writing stuff, but for now the tentative order of the lessons here is:

It is very likely that several of those lessons will be broken down into multiple smaller lessons. I advise that we keep them together in one file for now and break them up as needed once things start getting too long.

PLEASE

If you have feedback about the order or content of any of the lessons let someone know. Feel free to simply add your feedback to the lessons themselves or drop it in Gitter somewhere (you might ping @codyloyd, I'm kind of heading the project at this point).

NOTES:

  1. May be a good idea to move Arrays to second-steps... it's really hard to do too many useful things with arrays without using loops or functions, neither of which we've learned yet in first-steps. I'm leaving it for now, but may consider moving it later.

File: archive/README.md

Odin's Recycle Bin

Files end up here for one or more of the following reasons:

  • Lesson/documentation file was unused
  • Significant part of the lesson/documentation file was rewritten
  • Lesson was replaced by another lesson
  • Lesson was deemed outdated and consequently removed from the curriculum
  • and more...

File: archive/README-old.md

Welcome to The Odin Project Curriculum

The Odin Project (also known as TOP) is an open-source community for learning full-stack web development. Our mission is to provide a comprehensive curriculum to learn web development for free. We help our students learn the skills and build the impressive portfolio of projects they need to get hired as a web developer.

The curriculum is divided into distinct courses, each covering the subject language in depth. Each course contains a listing of lessons interspersed with multiple projects. These projects give students the opportunity to practice what they are learning, thereby reinforcing and solidifying the theoretical knowledge learned in the lessons. Completed projects may then be included in the student's portfolio.

Lessons are structured through a combination of original written content and a compilation of carefully curated resources from the web. This is where the contributing happens!

This repository houses the curricular content used in The Odin Project website. (cf. this repository which houses the front-end and back-end code.)

The TOP community can be found in our Discord chat rooms.

Contributing

The Odin Project depends on open-source contributions to improve, grow, and thrive. We welcome contributors of all experience levels and backgrounds to help maintain this awesome curriculum and community.

Lessons/Courses in Development

We are constantly making improvements to the curriculum, and new lessons are always in the works. However, writing new lessons is very time consuming and is done for free. If you would like to know specifics about work on new lessons, ask in the Discord chat, or keep an eye on this repo.

In flight curriculum initiatives

You can see what we're working on here.

If you would like to help us develop any lessons, please read our contributing guide to find out how you can contribute.

A non-exhaustive list of what you can contribute to help us:

  • Correcting typos and other grammar errors.
  • Rewriting lesson sections to make them clearer and easier to understand.
  • Fixing broken links.
  • Adding new resource links you think would make a lesson better.
  • Working on new lessons and projects. You can choose to work on parts of a lesson that are outlined in the progress list on lesson plans or you can work on completing an entire lesson yourself.

To find out more about how you can contribute, please read our contributing guide.

For more information about The Odin Project, go to theodinproject.com.

For the source code to The Odin Project's main website (which pulls in this curriculum), check out the github repo here.

Happy Coding!

* See license.md for usage details.

Created by Erik Trautman

The Odin Project - JavaScript Curriculum

Mission statement

Our main focus is the cultivation and sequencing of the best free resources around the internet. We believe wholeheartedly that everything one needs to know to become employed can be found for free online. However, for the average new learner, the vast quantity (and widely varying quality) of resources makes it difficult to make meaningful progress. Therefore, we have devised three basic steps to fix this.

  1. We have created a curriculum that attempts to find the optimal sequencing of information. This curriculum is intended to take someone from knowing literally nothing about web development to a point where they could be employed as a Junior Developer.
  2. For each topic in the curriculum, we try to find the best free resources on the internet that teach that topic. We will often link multiple resources so as to not rely too much on a single source of information. If good resources cannot be found, we write our own, but we prefer primary links to external sites.
  3. We invent and cultivate projects that give learners a chance to practice what they have learned and to integrate skills along the way. These projects increase information retention, give the learner a chance to experiment, and allow the learner to build an impressive portfolio.

Additionally, we have made our learning materials completely open source. This means that if anyone comes across a resource that is better than what is currently included in our lessons, that person is free (and encouraged!) to add them, which improves our curriculum over time and helps it to stay up to date.

Contributing

If you would like to contribute to this project, please contact us here.

File: markdownlint/docs/README.md

TOP Custom Markdownlint Rules

This directory contains documentation for our custom rules for linting Markdown files using the markdownlint-cli2 tool. These rules supplement the default rules provided by markdownlint to enforce our curriculum's layout style.

Table of Contents

How to Contribute

Make sure you have read our general contributing guide, as it contains information that is important for all of our repos.

This contributing guide assumes you have followed the instructions in the general contributing guide to fork and clone this curriculum repo.

If you have a suggestion for a new linting rule, please do not open a pull request (PR) directly. Instead, open an issue with the full proposal so the team can discuss it first.

Custom Rules

File Structure

Every custom rule should have its own directory inside /markdownlint (parent directory to this file), in the following format:

text
TOPXXX_ruleName/
├── TOPXXX_ruleName.js
└── tests/
    ├── TOPXXX.test.js
    └── ...<any number of markdown test files>.md

It must also have a corresponding TOPXXX.md documentation file inside /markdownlint/docs (same directory as this file) that explains how the rule works, whether it includes auto-fix behaviour (and in what way), and the rationale behind the rule.

A path to the TOPXXX_ruleName.js file must also be added to the customRules array in the .markdownlint-cli2.jsonc configuration file in the root of this repo.

Rule Code

Refer to markdonwlint custom rule documentation for general information about how to write a custom rule.

Our custom rules must also ensure the following properties contain the following values:

  • names: An array with two elements:
    • The rule code (e.g. TOP001)
    • The rule name in kebab-case (e.g. descriptive-link-text-labels)
  • parser: Must be set to markdownit
  • information: A new URL() object that links to the rule's documentation file

Tests

Tests are run via Node's built-in test runner. All rules require the following:

  • Any number of markdown files containing only violations of the respective rule. These files must not include violations of other rules.
  • A markdown file containing no rule violations.
  • A .test.js file containing tests that:
    • Show the rule links to the correct documentation file
    • Demonstrate the correct error output when linting markdown files with rule violations (will indirectly test for the correct rule name/description as they are included in the error output)
    • Demonstrate the file with no rule violations has no error output

For rules that contain auto-fix behavior, the following things are also required:

  • Any number of markdown files that contain the intended "fixed" contents of other test markdown files (the intended result of running npm run fix on them)
  • Tests that:
    • Show no error output from any "fixed" markdown files
    • Show fixing a test markdown file results in the same contents as the respective "fixed" markdown file

Tests can be run by running npm run test.

Test Utilities

Two utility functions are provided in /markdownlint/test_utils for testing both linting and fixing: getLintErrors and fixLintErrors. For both of these, require them into the test file and call them with __dirname as an argument. These will each return an async function that's relative to the test file, so you only need to pass them paths relative to the test file.

  • getLintErrors takes a string containing the relative path to a test markdown file, and returns a Promise that resolves to an array containing each violation's error output as a separate string.
  • fixLintErrors takes a string containing the relative path to a test markdown file, and returns a Promise that resolves to a string containing the contents of the file after fixing all fixable violations.

File: markdownlint/docs/TOP001.md

TOP001 - Descriptive link text labels

Tags: accessibility, links

Aliases: descriptive-link-text-labels

Fixable via script: Not fixable due to being context-based

This rule is triggered when a link has a text label that meets one of the following criteria:

  • Uses the words "this" or "here"
  • Exactly matches one of our blacklisted link texts (commonly used text labels that are insufficiently descriptive)

Example of links that have text labels that include "this" or "here":

markdown
You can read more about variables in JavaScript [here](https://example.com).
[This article](https://example.com) provides more information about closures.

To fix this issue, remove the words "here" and "this" and use more descriptive text that clearly conveys the purpose or content of the link. You may need to also update the surrounding text. The following code block demonstrates how the links from above could be fixed:

markdown
You can read more about [variables in JavaScript](https://example.com).
[An in-depth article about closures in JavaScript](https://example.com) provides more information.

Note that even if the text is somewhat descriptive, this rule will still flag occurrences of "this" or "here":

markdown
[Here is a comprehensive guide to understanding closures](https://example.com).

In this case, it's still better to rephrase the link text to be more concise and descriptive:

markdown
[Comprehensive guide to understanding closures](https://example.com)

Additionally, consider including relevant keywords in the link text to provide more context:

markdown
For more information, refer to the [official documentation on closures in JavaScript](https://example.com).

This rule is also triggered if the entire link text exactly matches any of our blacklisted texts, which consists of commonly used text labels that are not sufficiently descriptive while not containing "this" or "here". Examples include (but are not limited to) "video", "article", "an article", "docs", "the docs", "documentation", and "homepage":

markdown
For more information, watch this [video](https://example.com) about the CSS box model.
You can read more about it in the [documentation](https://example.com).

The above links can be rephrased to be sufficiently descriptive by themselves:

markdown
For more information, watch this [video about the CSS box model](https://example.com).
You can read more about it in the [Proc class documentation](https://example.com).

Rationale

Descriptive link text improves accessibility by providing clear and meaningful context about the link's destination. Links with text labels using the words "this" or "here" tend to be less descriptive and may not effectively convey the purpose of the link to users, especially those using assistive technologies. Similarly, text labels like "video", "article" or "docs" act in the same way for users of assistive technologies, requiring knowledge of the surrounding non-link text for context. By using specific and relevant keywords in the link text, you can enhance the user experience and make it easier for users to understand the context and purpose of the link.

File: markdownlint/docs/TOP002.md

TOP002 - No inline code in headings

Tags: headings

Aliases: no-code-headings

Fixable via script: Mostly fixable (see below for clash details)

This rule is triggered when a heading contains inline code. For example:

markdown
## Using `console.log()` for Debugging

To fix this issue, remove the inline code from the heading and rephrase it to convey the same meaning without using code:

markdown
## Using console.log for Debugging

This rule's fixer currently may not work correctly if there are spaces within inline code blocks. For example, the following scenario would have the default rule MD038 - no spaces in code run its fixer first.

markdown
### A `space `inside a heading



### A `space`inside a heading

Notice how the space has been removed from inside the inline code block, but the code block has not been removed. Running the fix command will remove the inline code, but the space would then be missing between the words "space" and "inside".

Rationale

Headings should be concise and descriptive, providing a clear overview of the section's content. Including inline code in headings can make them less readable and may not effectively convey the purpose of the section to users.

File: markdownlint/docs/TOP003.md

TOP003 - Default section content

Tags: content

Aliases: default-section-content

Fixable via script: Default section content will be added or reworded accordingly.

This rule is triggered when a section does not have the expected default content or structure. The affected sections include:

  • Lesson overview
  • Assignment
  • Knowledge check
  • Additional resources

Contains content before or after list

There should be no content before or after the unordered list of items in the "Lesson overview", "Knowledge check", and "Additional resources" sections, other than the default content.

Incorrect (content after the list):

markdown
### Lesson overview

This section contains a general overview of topics that you will learn in this lesson.

- LO item

Some additional content

Incorrect (content before the list):

markdown
### Lesson overview

This section contains a general overview of topics that you will learn in this lesson.

Some additional content

- LO item

Correct:

markdown
### Lesson overview

This section contains a general overview of topics that you will learn in this lesson.

- LO item

Contains incorrect default content

Each section should contain the correct default content.

Incorrect (wrong default content before the list):

markdown
### Lesson overview

This section has the incorrect text following the heading.

- LO item

Correct:

markdown
### Lesson overview

This section contains a general overview of topics that you will learn in this lesson.

- LO item

Incorrect (missing the list after the Additional Resources heading):

markdown
### Additional resources

This section contains helpful links to related content. It is not required, so consider it supplemental.

Correct:

markdown
### Additional resources

This section contains helpful links to related content. It is not required, so consider it supplemental.

- AR item

Incorrect (contains a nested list):

markdown
### Lesson overview

This section contains a general overview of topics that you will learn in this lesson.

- An item
  - A nested item

Correct:

markdown
### Lesson overview

This section contains a general overview of topics that you will learn in this lesson.

- An item
- Another item

Missing "Assignment" section div wrapper

The "Assignment" section should contain a div with the correct attributes. Note that not all assignment content needs to be wrapped in this div, but it must at least exist in this section.

Incorrect (missing the div wrapper with the correct attributes):

markdown
### Assignment

Assignment content

Correct:

markdown
### Assignment



Assignment content

Rationale

Including default content in specific sections helps maintain consistency across lessons and provides learners with clear expectations. It also ensures that essential information is not overlooked and that the curriculum structure remains organized and easy to navigate.

File: markdownlint/docs/TOP004.md

TOP004 - Lesson headings

Tags: headings

Aliases: lesson-headings

Fixable via script: Not fixable due to being context-based

The rule is triggered when the headings in the document do not match the specified list of required headings. It compares each heading in the document with the corresponding required heading and reports any mismatches.

Currently, the required headings depend on the content's type:

Lesson headings structure

markdown
### Introduction
### Lesson overview
### A custom heading
* (Wildcard: Any heading at any level)
### Assignment
* (Wildcard: Any heading at any level)
### Knowledge check
### Additional resources (optional)

The wildcard symbol * represents any heading text at any level. This means that any heading will be considered valid, regardless of its actual text content.

The Additional Resources section should only be present if it contains resources. If it is empty, the section should not be present at all.

Project headings structure

markdown
### Introduction
* (Wildcard: Any heading at any level)
### Assignment
* (Wildcard: Any heading at any level)

Similar to the lesson headings structure, the wildcard symbol * in the project headings structure allows for any heading text at the specified level.

Guide headings structure

markdown
### Guide: * (Any descriptive title)
* (Wildcard: Any heading at any level)

Guide files are reference content stored in folders ending with _guides (e.g., installation_guides/). They must start with a heading beginning with ### Guide: followed by a descriptive title. After that, any heading structure is allowed since guides are flexible instructional content.

Files located in *_guides/ folders automatically use this guide structure instead of the lesson or project structure.

Exceptions

There are a few lessons where it does not make sense to enforce any particular heading structure, such as course intro lessons or course conclusions. Lessons with the following file names are exempt from this rule:

  • how_this_course_will_work.md
  • conclusion.md
  • conclusion_full_stack_javascript.md
  • conclusion_ruby_on_rails.md

Rationale

Enforcing a consistent heading structure improves readability, organization, and navigation. By specifying a required heading structure, authors can ensure that their documents follow a standardized format and include all the necessary sections. This rule helps maintain consistency across multiple documents and makes it easier for readers to locate specific information.

Explore Related Technologies & Topics

View All 9,111+ Repositories →

Discover similar high-velocity repositories, agent skills, and OpenAPI specifications across the ecosystem.

#css Browse css catalog → #curriculum Browse curriculum catalog → #html Browse html catalog → #javascript Browse javascript catalog → #lessons Browse lessons catalog → #node Browse node catalog → ⚡ MCP Servers Model Context Protocol → 🧠 Agent Skills Prompt & rule files → 🔌 OpenAPI Specs REST & Swagger schemas →