# 30 Days Of JavaScript: thirty markdown folders and no package.json > 30 Days Of JavaScript is a self-study curriculum that lives entirely in numbered markdown files, running from Introduction on day 01 to a set of mini projects on days 24 to 30. There is nothing to install, no licence on record, and the author's own description warns the thirty days may take a hundred. **Asabeneh/30-Days-Of-JavaScript** — 30 days of JavaScript programming challenge is a step-by-step guide to learn JavaScript programming language in 30 days. This challenge may take more than 100 days, please just follow your own pace. These videos may help too: https://www.youtube.com/channel/UC7PNRuno1rzYPb1xLa4yktw - Repository: https://github.com/Asabeneh/30-Days-Of-JavaScript - Stars: 46,847 · Forks: 10,457 - Language: JavaScript - License: not declared - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/asabeneh-30-days-of-javascript ## There is no package manifest, so the repository cannot be installed Everything 30 Days Of JavaScript is, sits in thirty numbered folders. Day 02 is ./02_Day_Data_types/02_day_data_types.md, day 12 is ./12_Day_Regular_expressions/12_day_regular_expressions.md, and day 23 is ./23_Day_Event_listeners/23_day_event_listeners.md. The root also carries readMe.md, an index.html, a data/ folder and an images/ folder, and that is the whole inventory. There is no package manifest, no lockfile, no build script and no test command, so there is nothing to install, nothing to import and no version constraint your project inherits. That is the difference from a reference site, and it is the decision the reader is making. A reference answers the question you have now. This sequence decides what you read and in what order, and hands you something to finish. The trade is the fixed order, which is also its main weakness: there is no way to skip day 09 because you already know map and filter, and the day numbers are the only navigation the repository offers. Getting started means cloning the repository and opening readMe.md. A YouTube channel is linked from the description as a companion. No file in the repository states a required Node version, browser or editor, so the environment is whatever you already have. ## Days 24 to 30 are seven builds, not seven more exercises The sequence changes shape in the last week. Days 01 to 23 are topic days: Introduction, Data Types, Booleans Operators Date, Conditionals, Arrays, Loops, Functions, Objects, Higher Order Functions, Sets and Maps, Destructuring and Spreading, Regular Expressions, Console Object Methods, Error Handling, Classes, JSON, Web Storages, Promises, Closures, Writing Clean Code, DOM, Manipulating DOM Object and Event Listeners. Day 24 is Mini Project: Solar System, and from there every entry is a project: two World Countries Data Visualization days, a Portfolio, a Leaderboard, animating characters, and Final Projects. Read that as a workload, not a curriculum. Three quarters of the sequence is syntax and language mechanics you can type into a console; the last seven days need a browser, assets and a data source. Days 25 and 26 run the same country dataset twice, which reads as a first pass and a second pass rather than two different projects. The gap worth naming is the dataset. The repository root has a data/ folder and an index.html, and the project days need a country list from somewhere, but no file in the repository states where that data comes from or what licence it carries. Anyone planning to teach from this sequence has to resolve that before day 25 rather than at it. ## Day 01 lives in two places and the day 10 filename has mixed casing The index table points day 01 at ./readMe.md, at the repository root. The root also contains a folder called 01_Day_Introduction. So a reader who clicks the table and a script that loops over the day folders land on different files for the same day, and which one is current is not something the table tells you. The naming is uneven in other ways. Day 10 is stored in 10_Day_Sets_and_Maps/ with the file named 10_day_Sets_and_Maps.md, so the capitalisation changes between the folder and the file. Day 24 is 24_Day_Project_solar_system in the root listing while the day 11 folder is 11_Day_Destructuring_and_spreading, and the table's own link text uses a third variation. On a case-insensitive macOS or Windows checkout none of this surfaces. On Linux, or in any pipeline that builds URLs from folder names, a case mismatch is a broken link rather than a cosmetic difference. For a repository with no build step and no link checker in the root entries, that is a real maintenance surface. A team mirroring these files into its own docs should normalise the names rather than inherit them. ## The default branch is master and there is no release to pin The repository has no GitHub releases, and the default branch is master rather than main. The last push was on 2026-08-27 and the project is not archived, so the content is being touched, but there is no tag to point at and no version string in any manifest. That matters more for a curriculum than it does for a library. A library pins a version and the code stops moving under you. Here every file is edited in place, so a link to ./12_Day_Regular_expressions/12_day_regular_expressions.md resolves to different content over time, and a team that links into it from internal documentation is quietly depending on a moving target. If you use it, record the commit you read. The branch name catches tooling out too. Any script that assumes main will not find the code, and the day-folder pattern is the only stable address scheme here, so a fetch has to be written against master explicitly. ## Ten language links, eleven translation trees The introduction links ten versions of itself: English, Spanish, Italian, Russian, Turkish, Azerbaijan, Korean, Vietnamese, Polish and Portuguese. The root holds those directories and one more, French/, which no link in the introduction points to. A French reader browsing the repository finds the day folders; a French reader following the introduction does not. The translations are full parallel trees rather than per-day overlays, since each language directory carries its own readme, Spanish/readme.md, RU/README.md and Italian/readMe.md among them. That is the right choice for a reader who wants the whole sequence in one language, and the wrong one for maintenance. A correction to the English day 12 does not propagate, and no translation script appears among the root entries. The per-day coverage is the open question. The English days live at the root while the translated versions sit in language folders, and no file in the repository says whether every language carries all thirty days or only its introduction. A team choosing a language for a classroom has to check the specific day rather than trust the language list. ## The repository records no licence, so there is nothing to copy from The project metadata carries no licence identifier and the root has no LICENSE file. Among the top-level entries there is a .gitignore and a .github/ directory, and nothing that grants permission. The practical effect is narrower than it sounds but real. Reading the lessons at their published URL and working through the exercises needs no permission, and that is what the author intends. Forking the repository, republishing the text in a company handbook, or folding the exercises into an internal course is a different act, and there is no stated grant for it. This is not a legal opinion, only the observation that the usual answer to can I vendor this is normally a licence file, and here the file is absent. Worth contrasting with the funding side, which is explicit. The README carries sponsor sections pointing at GitHub Sponsors and PayPal, plus a commented-out bootcamp form link. Money is handled in the open; permission to reuse is not mentioned at all. ## The README you land on is a link table, and it says the pace is wrong The most useful line in the project is in its description rather than its README: the challenge may take more than 100 days, and you should follow your own pace. That sits directly against a title and a thirty-row table numbered 01 to 30, and the author is warning you off the arithmetic in the title. The README itself is mostly the table plus funding blocks. Its own table of contents has two entries, the challenge index and the sponsor section, and the file opens with a commented-out bootcamp promotion. There is no stated method: no exercises-per-day estimate, no assessment, no statement of what a reader should be able to do afterwards. The structure tells you the order and nothing about the pace. So the honest way to use this is as a syllabus you re-time, not a schedule you follow. Read the table, count the days you can actually give it, and expect the project week to cost more than the topic week, since seven builds replace seven exercises and the data source for the visualization days is not identified anywhere in the repository. ## Conclusion 30 Days Of JavaScript fits a self-learner who wants a fixed order and a project to finish at the end, and a team willing to vendor the markdown into its own documentation. It does not fit a team that needs a citable reference, a licence to copy from, or a version to pin. Verify first that the day you intend to teach still matches what your engineers believe about the language, because the files change in place and the last push was on 2026-08-27. ## FAQ ### Is 1 month enough to learn JavaScript? The project's own description says the 30 days challenge may take more than 100 days and tells you to follow your own pace, even though the folders are numbered 01 to 30. The sequence starts at Introduction and Data Types, so it is written for someone beginning rather than someone reviewing. ### Can you show me how to build 30 JavaScript projects in 30 days? The sequence is not 30 projects. Days 01 to 23 are topic days covering Data Types, Arrays, Functions, Classes, Promises, Closures, the DOM and event listeners, and the projects begin at day 24 with Solar System, followed by two World Countries Data Visualization days, a Portfolio, a Leaderboard, animating characters and Final Projects. ### Does 30 Days Of JavaScript have a package.json or an install step? No. The root holds thirty numbered day folders, translation directories, readMe.md, an index.html and data/ and images/ folders, with no package manifest in the root entries. There is nothing to install or import, and the day files are markdown you read and run by hand. ### Can I reuse the 30 Days Of JavaScript lessons in my own team's docs? The project records no licence and the root carries no LICENSE file, so there is no stated permission to copy, fork or redistribute the text. Reading it where it is published needs nothing further, and anything beyond that is a question for the author rather than something the repository answers. ## Sources - [Asabeneh/30-Days-Of-JavaScript on GitHub](https://github.com/Asabeneh/30-Days-Of-JavaScript) - [Issues](https://github.com/Asabeneh/30-Days-Of-JavaScript/issues) - [README](https://github.com/Asabeneh/30-Days-Of-JavaScript/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/asabeneh-30-days-of-javascript