Project Bootstrapping and Enforcing Industry Standards with Starter.dev

Why Use Starter Kits?

Whenever developers start a new project, they typically run a command similar to npx init <library/framework>. This command provides the bare minimum for the technology specified in order to begin work, and does not include key features that developers utilize such as testing, Storybook, data management, and UI toolkits.

Configuring these tools can be cumbersome and single-threaded, causing early delays to new software projects.

Additionally, developers have to make decisions on how to configure these tools for best practices, such as linting rules, based on the technologies they’ve selected.

The starter.dev kits provide solutions to these problems, with all the desired tools configured out-of-the-box with industry best practices in mind.

Now, developers can run the CLI script, and have the full repository running with zero-configuration in minutes instead of hours. This allows teams to begin building products in the first hour of starting, instead of just the first day.

Why a GitHub Clone?

This Dot Labs worked with the Angular team to create a resource showcasing Angular’s features, and help developers learn best practices for building with the framework.

Through conversations with the Angular team, we determined that a clone of GitHub would be an ideal example project because of its verbose API and familiarity among developers. It would allow us demonstrate the following key features:

• Routing
• Forms
• State Management
• API interactions - REST & GraphQL
• Authentication

To facilitate these requirements, we implemented the following features to best demonstrate the framework features:

• OAuth for authentication and global user state management
• A simplified user dashboard to demonstrate API interactions that could be demonstrated consistently across all GitHub API versions
• User and Organization profiles with repository search and filtering to demonstrate forms
• Repository view with file tree exploration and file viewer to demonstrate dynamic and advanced routing as well as localized state management
• Repository issues and pull requests viewing, demonstrating design reuse, forms, and dynamic routing

Enabling Developer Collaboration Across Several Sub-Projects

Early on the team identified two key issues: (1) organization of several unique starter kits and (2) automated publishing of the kits under a centralized CLI.

We solved this by utilizing Yarn Workspaces to generate a monorepo where we could store each kit in its own file directory while still accessing them for both the CLI and website documentation.

We chose a CLI over GitHub templates for a variety of reasons - the primary reason being to avoid maintaining repositories for each unique kit.

By choosing a monorepo instead, the CLI is able to read metadata for each of the starter kits via their package.json definitions and automatically generate the CLI options that are offered to users at runtime.

Additionally, the website is able to utilize each kits’ README.md to generate the documentation pages for how to use the kit.

These benefits allowed our team to work on different kits independently, thus allowing us to increase the number of kits we could develop in tandem without degrading the developer experience.