Consolidate Core Dojo Packages Into a Single Monorepo

[nicknisi]

The Dojo team is considering consolidating the core Dojo 2+ repos into a single monorepo for ease of development, maintenance, packaging, and versioning, while still deploying separate packages for the time being.

Background

Having separate repositories for each of the core aspects of Dojo presents a number of challenges.

• Setting up a local development environment with multiple dependent repositories can be difficult as packages need to be linked to interoperate together.
• Releasing each individual Dojo package is non-trivial and time consuming.
• It can be difficult for users unfamiliar with the package structure to know the appropriate repositories to file issues.
• Better tooling exists to aid in the creation of multiple, interdependent packages using a single repository, such as Lerna.
• It is a time-consuming task to maintain version number consistency between packages and their dependencies.

Consolidating the core packages into a single repository will allow the team to streamline the development and release process while still maintaining consistent versioning and simplifying the development process.

What are the benefits of a core monorepo?

• A better entry point repository for contributors and users
• A single source of truth for issues and pull requests relating to core Dojo packages
• Having a core repository for Dojo 2+ can be a better repository to add Gitter to
• Easier deployments with better tooling using Lerna.
• Easier development environment setup

Core Dojo packages

The following packages are considered to be “core” dojo packages as they have a lot of interdependency and are crucial to the core Dojo development experience. They will be consolidated into a single, repository while maintaining the git history of each.

• dojo/has
• dojo/shim
• dojo/core
• dojo/i18n
• dojo/widget-core
• dojo/routing
• dojo/stores

Other packages that are not considered “core” features in Dojo include loader, widgets, themes, test-extras, and interop. For now, we should consider leaving these as separate packages and repositories.

Why separate packages?

If we are considering consolidating the core Dojo repos, why are we still publishing separate packages to npm? The biggest benefit to this is that it allows us to continue on the 2.x release as the actual published artifacts should not be affected by the repository changes. Publishing a single “core” repository is up for discussion, but it would result in a major release. A single package release is also being considered and will be discussed in another issue.

Requirements

• The history of each of the consolidated repositories needs to be maintained.
• The release process needs to be simplified.
• The development environment setup needs to remain simple to setup.
• A name for the monorepo needs to be determined and needs to make and line up with a potential Dojo core package name in the future
  • dojo/dojo is an obvious choice but it is the current home of the Dojo Toolkit
    • We could move this to something else such as dojo/dojotoolkit but that could result in accidentally upgrading anyone pulling the Dojo Toolkit source directly from Github.
  • dojo/core is another obvious choice but it is currently in use as well.

[nicknisi]

A proof of concept repo containing the consolidated core repos with full git history for each is at https://github.com/nicknisi/dojo.

[nicknisi]

Based on several factors, it seems that the best name for this repository is dojo/framework. This also leaves open the possibility of a future, single package called @dojo/framework.

[KevinHua]

@dojo/framework is a long name since it will be used frequently here and there. I prefer a short name such as @dojo/lib or @dojo/corelib

[tomdye]

If widgets will live outside of the mono-repo can widget-core not be renamed to widget?

[agubler]

The main framework repos have been consolidated into a single repo and single npm package.