A developer needs to manually check out the renovate PR, run the changelog command e.g. yarn change, and commit the generated change files.

This is tedious and slows down the update process.

Renovate postUpgradeTasks

Renovate provides a postUpgradeTasks feature that allows running commands after an upgrade.

We can leverage this to automate changelog updates.

Please note this is only available in self-hosted renovate instances. If you are using the hosted version of renovate, a custom pipeline/action can be created to automatically add the changeset commits.

Configuration

Add the following to your Renovate configuration file (renovate.json):

  "postUpgradeTasks": {
    "commands": [
      "yarn change --type patch --message \"$(git show -s --format=%s | sed 's/\"/\\\"/g')\""
    ],
    "fileFilters": ["**/package.json"]
  },

Explanation

• postUpgradeTasks.commands: Runs yarn change automatically, using the latest commit message as the changelog entry.
• fileFilters: Ensures the command runs only when package.json changes.
• Escaping Quotes: The sed command prevents issues with double quotes in commit messages.

Benefits

✅ No more manual changelog updates for dependency upgrades.
✅ Faster PR handling and merging.
✅ Consistent changelog entries.

With postUpgradeTasks, Renovate can handle dependency updates more efficiently by automating changelog generation. Try adding this to your workflow and eliminate the manual effort!

The post Automating Changelog Updates in Renovate Bot PRs appeared first on onthecode.

Before you know it, your app looks like a patchwork of mismatched components.

What is a Design System?

A design system is a collection of reusable components, design principles, and guidelines that help teams build consistent and scalable user interfaces.

It serves as a single source of truth for both designers and developers.

Key Elements of a Design System

Design Tokens

The smallest reusable design properties, such as colors, typography, spacing, and shadows. Instead of hardcoding #FF5733 as a color, you define primary-color and apply it everywhere.

Component Library

A set of reusable UI elements like buttons, forms and modals that adhere to design and accessibility standards.

And to enforce design standards in code, we need a front-end framework (React, Angular, Vue, etc.).

Documentation

Usage instructions, design principles, and accessibility rules to ensure consistency.

How It Works in Practice

Imagine you work at a company with multiple teams working on a single product.

Instead of every team creating their own version of a “Submit” button with slightly different padding, font sizes, and colors, you define a standard button component in your design system.

This button is:

• Styled according to brand guidelines.
• Accessible by default (keyboard navigation, proper contrast, etc.).
• Easily updated — fix it once, and every instance updates automatically.

Why Do Companies Use Design Systems?

The world’s leading companies — Google, Airbnb, IBM, and Microsoft — all use design systems to scale their products.

Here’s why:

Scalability for Large Teams

As products grow, maintaining UI consistency becomes harder.

A design system provides a structured foundation that scales.

Faster Development

Developers don’t have to reinvent the wheel every time they build a new feature.

With a component library, they can reuse existing components, reducing development time significantly.

Consistent UI

A design system ensures that every product maintains a cohesive look and feel.

Without one, different teams may implement slightly different versions of the same components.

Improved Collaboration

Designers define the system.

Developers implement it.

Everyone works from a shared set of rules rather than treating design and development as separate silos.

Accessibility and Usability Standards

All users, including those with disabilities, should be able to use the product effectively.

A design system integrates accessibility best practices into the components from the start.

Design System Examples

These are some of the great examples of solid design systems that power thousands of apps:

• Google’s Material Design
• IBM’s Carbon
• Microsoft’s Fluent
• Atlassian Design

Google created Material Design as a design system to unify the user experience across Android, web, and mobile apps.

It includes everything from typography guidelines to pre-built UI components.

Result? Hundreds of apps now have a consistent and user-friendly UI.

How to Build a Design System

Creating a design system isn’t an overnight task. Here’s a simplified roadmap to get started:

Step 1: Audit Your Existing UI

• Identify inconsistencies in design and code.
• Take inventory of UI components used across your product.

Step 2: Define Design Tokens

• Establish a set of global styles for colors, typography, spacing, and shadows.
• Use a tool like Style Dictionary or CSS variables to manage tokens.

Step 3: Create a Component Library

• Build and document reusable UI components using Storybook.
• Ensure each component meets accessibility standards (ARIA roles, keyboard navigation, etc.).

Step 4: Document Everything

• Write clear usage guidelines for each component.
• Explain when and how components should be used.
• Provide code snippets and design mocks.

Step 5: Adopt a Versioning Strategy

• Use Semantic Versioning (SemVer) to track updates.
• Assign ownership — who maintains the design system?
• Schedule regular audits to ensure it stays relevant.

Common Challenges (and How to Overcome Them)

Even the best design systems face hurdles. Here’s how to tackle them:

“Teams resist adoption.” 

💡 Solution: Educate stakeholders on the time saved by using pre-built components. Offer workshops or demos.

“Keeping the system updated is hard.” 

💡 Solution: Assign a dedicated design system team responsible for maintenance and updates.

“One-size-fits-all doesn’t work.” 

💡 Solution: Allow for controlled flexibility. Some components may need customisation per product.

Conclusion

If your product is growing without a design system, you’re setting yourself up for technical debt and UI inconsistency.

A well-structured design system helps teams move faster, collaborate better, and ship high-quality, scalable UI.

Whether you’re a designer, developer, or product manager, investing in a design system will make your workflow smoother and more efficient.

The post What is a Design System? appeared first on onthecode.

Let’s understand what defaultProject is and when you might need it.

What is default project in Angular?

In Angular, a “default project” refers to the primary application or module within an Angular workspace.

An Angular workspace is essentially a project container that can hold multiple projects, each of which can be an Angular application, library, or other related modules.

When you create a new Angular workspace using the Angular CLI, it automatically generates a default project for you.

ng new my-angular-app

This default project is often named “app” by default.

It serves as the main entry point for your application and includes the initial components, modules, services, and other files necessary to get your Angular application up and running.

You can also specify a different name for the default project during the creation of the workspace using the --defaultProject flag:

ng new my-angular-app --defaultProject=my-default-app

In this case, the default project is going to be “my-default-app” instead of the usual “app.”

Why do we need to specify defaultProject in Angular?

You can have multiple projects within a single Angular workspace e.g., an admin panel and a user-facing frontend.

Each project can have its own configuration, dependencies, and codebase.But they can also share common resources and libraries within the workspace.

Angular CLI assumes you may create multiple projects in your workspace. And tries to help you by specifying the default project for you.

Does angular require defaultProject in angular json file?

Angular itself does not require a defaultProject in the angular.json file.

The defaultProject property is completely optional. It specifies which project to build & serve when a project name is not provided in the command line.

However, there is an exception.

If you have multiple projects in your workspace and you’re running a command that requires a project name (like ng serve or ng build) without specifying a project, then defaultProject is needed to tell Angular which project to apply the command to.

If you only have one project in your workspace, or you always specify your project when running commands, then you don’t need defaultProject.

In conclusion, Angular 14 (or any version) does not require defaultProject, but it can be helpful in multi-project workspaces.

The post Does Angular require defaultProject property? appeared first on onthecode.