Dojo 1 core is still maintained as development focuses on modern Dojo
Dojo 1 - the Dojo 1 toolkit core library.
At a glance
- What is it?
- The foundation package of the Dojo 1 toolkit, holding DOM manipulation, events, promises, classes, data stores, drag and drop and internationalisation at version 1.18.0-pre. The README says plainly that it is still maintained while new development focuses on modern Dojo.
- Who is it for?
- Adopt Dojo 1 core if you are maintaining an existing Dojo 1 application and want the shared foundation modules without pulling in Dijit, because this package is the core and the README states it is still maintained. Do not start a new project on it: the README directs new development to modern Dojo, and the version string here is a pre-release of 1.18.0.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 66 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.
Editorial analysis
One sentence decides whether this is for you
The first substantive line of the README is a status statement rather than a feature list: this is the foundation package for the Dojo 1 toolkit, and while it is still being maintained, new development is primarily focused on modern Dojo.
That is the whole adoption decision in one sentence. Existing Dojo 1 code keeps getting fixes. New work belongs somewhere else, at dojo.io, with a technical status and roadmap at dojo.io/community.
The last push was on 2026-08-17 and the repository is not archived, so the maintenance claim has a date attached to it rather than being an indefinite promise. There are no GitHub releases for this repository, so the version is read from the package metadata instead.
Everything below describes what the package contains, which matters either way: whether you are extending an old application or deciding how to escape it, you need to know which modules are here.
The package is a bundle of independent sub-libraries
The README calls this package the core, and explains that it contains the most generally applicable sub-packages and modules. The list of what it covers is broad: Ajax, DOM manipulation, class-type programming, events, promises, data stores, drag and drop, and internationalisation.
That breadth cuts both ways. It means you can depend on the core without Dijit, the widget library, or the charting and GFX libraries, which are separate packages. It also means the package is large and you have no reason to take all of it.
The practical advice is to depend on the individual modules rather than on the bundle where your build allows it, because the AMD loader this toolkit provides loads small files only when needed and loads dependent files separately even when they depend on one another. That loading characteristic is the reason the package is structured as many small modules rather than one concatenated library.
The description field in package.json makes the same pitch in one line: a lightweight library that animates elements, manipulates the DOM and queries with easy CSS syntax without sacrificing performance.
The file layout is the architecture
The repository root is a flat list of modules, and it reads like an index of the library's capabilities. There is dojo.js as the main entry, has.js for feature detection, dom.js as the DOM hub, json.js, cookie.js, colors.js, currency.js, date.js and hash.js as utilities, and global.js for the global object.
The NodeList family is split by concern: NodeList.js, NodeList-dom.js, NodeList-data.js, NodeList-html.js, NodeList-fx.js, NodeList-manipulate.js and NodeList-traverse.js. That is a deliberate split so a build can include only the operations an application uses, which is the payoff of the AMD layout.
Class and object programming lives in _base/, with aspect.js for cross-cutting concerns and Stateful.js, Evented.js, Deferred.js and DeferredList.js for the object protocols. Then there are directories for io/ and the io.xhr layer, dnd/ for drag and drop, data/ for the data stores, fx/ for animations, date/ for date handling, errors/ for the error system, json5/ and the CLDR data in cldr/ for internationalisation. Two files are infrastructure rather than API: AdapterRegistry.js and OpenAjax.js, which are the compatibility layers from the era when the toolkit still had to satisfy older browser abstraction requirements.
_firebug/ is a development aid, and dojo.profile.js at the root is the build profile named by the dojoBuild field in package.json.
Build tooling is pre-modern and still coherent
The package metadata gives the version as 1.18.0-pre, a pre-release, which is the version string you would resolve from npm.
The build is driven by dojo.profile.js through the dojoBuild field, which is the toolkit's own build configuration rather than a bundler config. That means the historical build system is still in place, and it is why the package points its directories.lib at the repository root: the library is the root.
The test tooling is Intern, named intern-geezer as the package, with scripts split by where the tests run. test uses intern-client against tests/dojo.intern, test-remote uses intern-runner against the same config, test-local uses intern-runner against tests/dojo.intern.local, and there are coverage variants for each which pass reporters=lcovhtml. A separate test-proxy script runs with proxyOnly=true.
The split between client and runner is the interesting part. The dev dependencies are correspondingly dated: sinon at 1.12.2, glob at 3.2.7, jsgi-node and formidable from the same period.
A bower.json is also present, which dates the packaging conventions rather than the code.
Dual licensing gives you a choice, which is unusual and useful
The README states that the Dojo Toolkit, including this package, is dual licensed under BSD 3-Clause and AFL. The package.json license field spells the same thing as BSD-3-Clause OR AFL-2.1, with the OR making the choice explicit rather than cumulative.
Why the choice matters in practice: BSD 3-Clause is a permissive licence with an attribution requirement, while the Academic Free License is an open source licence whose obligations are considerably heavier and which includes provisions about distributing modified versions and about not imposing additional restrictions on the licensed work.
So the dual grant is not redundant. A commercial product that wants the minimum obligation picks BSD; a project with an open source policy that requires a recognised open source licence can point at the AFL. Without the dual grant you would have to choose one and possibly fail the other requirement.
The copyright statement is dated: the toolkit is copyright 2005 to 2018, JS Foundation. That range tells you the era of the codebase's peak development, and it is separate from the maintenance activity that continues today. Licence details are at dojotoolkit.org/license.
Note that GitHub's own classifier cannot place this project, reporting it as a custom licence, which is a limitation of automatic detection rather than a statement about the terms.
Where the rest of the toolkit sits, and where to go instead
The README's section on what to use Dojo for is essentially a map of the wider toolkit, and it is useful for deciding how much you want to take on.
Dijit is the widget framework, described as offering several dozen enterprise-ready widgets including buttons, textboxes, form widgets with built-in validation and layout elements, with themes for consistency, and as available for mobile environments as well.
The GFX API handles advanced vector graphics, rendering in a wide variety of formats with manipulation such as skewing, rotating and resizing, gradients and mouse event response.
dojox/charting covers data visualisation with 2D plots and animated charting elements. The dgrid widget provides lightweight, mobile-friendly grids and tables with in-cell editing, row and cell selection, column resizing and reordering, keyboard handling and pagination.
The last item is the one that keeps Dojo 1 relevant. Dojo is described as the officially supported framework for the ArcGIS API for JavaScript, and the README says learning Dojo will open doors to richer web mapping applications with that API. If your work is ArcGIS for JavaScript, that sentence is the reason to stay on this line rather than migrate.
For everything else, the README points at modern Dojo as the place where new development is focused.
Editorial conclusion
Adopt Dojo 1 core if you are maintaining an existing Dojo 1 application and want the shared foundation modules without pulling in Dijit, because this package is the core and the README states it is still maintained. Do not start a new project on it: the README directs new development to modern Dojo, and the version string here is a pre-release of 1.18.0. Verify first which sub-packages you actually need, since this package is broad and you may only want dojo/_base, dom and promise, and note that the dual BSD 3-Clause and AFL licence lets you choose either, which matters if your compliance process prefers one over the other.
Frequently asked questions
Is Dojo 1 still being maintained?
The README states the package is still being maintained while new development is primarily focused on modern Dojo. The last push was on 2026-08-17 and the repository is not archived, but the version in package.json is a pre-release, 1.18.0-pre.
What licence applies to the dojo core package?
The toolkit including this package is dual licensed under BSD 3-Clause and AFL, recorded in package.json as BSD-3-Clause OR AFL-2.1. You choose which terms apply rather than needing to satisfy both.
Does the dojo package include the Dijit widgets?
No. This package is the core and covers Ajax, DOM manipulation, classes, events, promises, data stores, drag and drop and internationalisation. Dijit is a separate package, as are the GFX API, dojox/charting and dgrid.
How are the Dojo core tests run?
With Intern. package.json defines test using intern-client against tests/dojo.intern, test-remote and test-local using intern-runner against tests/dojo.intern and tests/dojo.intern.local respectively, plus coverage variants that add reporters=lcovhtml.