Forem: oskhar

🚀 Commitizen: Making Git Commits the Right Way

oskhar — Thu, 17 Apr 2025 20:24:08 +0000

✅ Once you start using Commitizen, it’s hard to go back. Your future self (and your team) will thank you.

GDGoC-UINJKT / init-repo-template

🚀 Kickstart your next project with a clean, consistent, and collaborative-ready repo template — zero fuss, maximum clarity.

🚀 init-repo-template

A professional and opinionated GitHub repository template to improve consistency, collaboration, and long-term maintainability for open-source or private projects.

📦 Ready-to-clone setup for teams who care about clean Git history and a clear collaboration flow.

Why this template?

This template helps you avoid:

inconsistent commit messages
unclear contribution rules
repetitive repo setup across projects

It’s designed to be reusable, team-friendly, and tool-agnostic (not tied to Node.js projects).

What’s included ✨

.czrc for Commitizen-based interactive commits
Conventional Commits & semantic versioning support
Clear collaboration rules in collaboration_guide.md
GitHub-ready structure (.github, docs-friendly layout)

Getting started

1. Clone the template

git clone https://github.com/your-username/init-repo-template.git your-project-name
cd your-project-name

2. Read the collaboration guide

Before committing anything, read:

collaboration_guide.md

It explains commit rules, branching, PR flow, and review etiquette.

3. Initialize your repository

git init
git remote add origin <your-new-repo-url>
npm install -g

…

View on GitHub

Writing great code is only part of the job—communicating changes effectively is just as important. That’s where Commitizen comes in. If you’ve ever scrolled through a Git history and felt like deciphering commit messages was harder than debugging code, this tool is here to help.

🧠 Why Commit Messages Matter

Every team has seen it: a Git log full of mysterious messages like fix stuff, update, or the dreaded asdf. These commit messages make it hard to track down what changed, when, and why. A poorly written commit message not only wastes time during debugging or code reviews but also undermines the integrity of the development workflow.

High-quality commit messages help with:

🕵️ Tracking bugs and changes – When a bug is discovered, commit messages help pinpoint when the issue was introduced.
📜 Generating changelogs – For software release notes and user-facing documentation, clean commit messages provide clear references to new features or fixed issues.
🛠️ Simplifying releases and version bumps – Automated tools rely on commit structure to trigger semantic versioning and changelog creation.
🤝 Collaborating better in teams – New contributors or reviewers can quickly understand what’s happening without deep-diving into diffs.

Consistency in commit messages makes your Git history readable, actionable, and valuable—not just now, but months or years down the line.

✨ What is Commitizen, Really?

Commitizen (often abbreviated as CZ) is an open-source developer tool that standardizes commit messages by guiding developers through a prompt-based interface. It essentially replaces git commit with a smarter alternative: cz commit. This process reduces mental load and ensures messages follow a specific style guide.

Rather than typing:

git commit -m "Added feature X"

You run:

git cz

And get prompted for:

The type of change (e.g., feat, fix, chore, docs, etc.)
The scope of the change (e.g., component or module name)
A short description
A longer body if needed
Any breaking changes
Reference to issues (e.g., Closes #123)

This results in a commit message like:

feat(auth): add support for multi-factor authentication

This is particularly useful when using tools like:

semantic-release
standard-version
release-it

These tools rely on commit messages for changelog generation and version control, so Commitizen lays the groundwork for advanced automation.

🔍 Where Did Commitizen Come From?

Commitizen originated from the need to bridge the gap between human-readable commit logs and machine-readable metadata. As teams began to adopt automated release tools like semantic-release, a standard commit format became more essential than optional.

The community began to converge around the Conventional Commits specification—a formal specification for writing standardized commit messages. Tools like Commitizen were developed to simplify adherence to this standard without expecting developers to memorize the format.

Think of it this way: Git commit messages are one of the few ways developers communicate chronologically through a project. Commitizen helps make that communication clear, searchable, and contextual. It started small but has grown to be an essential part of many professional and open-source workflows.

💡 Why Use Commitizen?

Adopting Commitizen isn’t just about being more organized—it’s about setting the foundation for better tooling, collaboration, and long-term project health.

Some benefits in more detail:

✅ Commit Consistency -> Every commit follows the same format, so no more deciphering what final-update-really-this-time means. It introduces a shared language for your entire team.
📝 Auto-generated Changelogs -> Tools like conventional-changelog can parse your Git history and create beautiful changelogs automatically. This is crucial when shipping software, managing releases, or informing users.
🚀 CI/CD Integration -> Commitizen lays the groundwork for zero-touch deployments with tools like semantic-release. With the right commit message, your pipeline can automatically determine whether to bump a patch, minor, or major version.
🔬 Readable History -> git log transforms from a cryptic list of random strings into a story of your project's evolution. Developers can trace changes with clarity.
⏱️ Saves Time -> With commit prompts, developers don’t waste time formatting their messages or wondering what to write. Commitizen streamlines the process.
🌍 Community Standard -> It’s widely adopted in both small teams and large enterprises. Knowing Commitizen makes you more effective across different codebases.

⚙️ How to Get Started

You don’t need to reinvent your workflow—just drop in Commitizen and go.

1. 📦 Installation

Install it globally (to use across all projects):

npm install -g commitizen

Or locally for just one project:

npm install --save-dev commitizen

Global install is great for personal projects or experimentation. Local install is ideal for team environments to ensure consistent tooling for everyone.

2. 📐 Choose an Adapter

Adapters define how your commits should be structured. The most commonly used one is:

npm install --save-dev cz-conventional-changelog

This adapter uses the Conventional Commits specification. In package.json, add:

"config": {
  "commitizen": {
    "path": "./node_modules/cz-conventional-changelog"
  }
}

This config tells Commitizen to use the installed adapter when prompting for commits.

3. 🖊️ Start Committing

Once everything is installed, commit using:

npx cz

Or if installed globally:

cz

Commitizen will guide you through a series of questions. Your answers generate a properly formatted commit message. This is especially powerful for teams with mixed experience levels—everyone commits the same way.

You can also integrate with tools like husky or lint-staged to enforce commit linting automatically.

🧭 Beyond Basics: Making Commitizen Part of the Culture

Just installing Commitizen isn’t enough—it’s about changing habits and aligning the team.

Best practices to help it stick:

🧪 Pre-commit hooks with Husky -> Add Commitizen as a Git hook so every commit goes through the cz prompt. This ensures enforcement, not just suggestion.
📘 Update CONTRIBUTING.md -> Document how to commit and why it matters. Link to the Conventional Commits guide.
🧰 Automate with CI/CD -> Set up semantic versioning and changelog generation. When teammates see it working, they’ll get it.
🔁 Review Commit Messages in PRs -> Don’t just review code—review commit messages. Over time, writing good commits becomes second nature.
🎓 Train new contributors -> During onboarding, highlight how Commitizen improves code quality and deployment.

Culture change doesn’t happen overnight, but the benefits of consistent commits pay off quickly.

🛠️ A Real-World Template You Can Use Today

If you’re thinking: “This sounds great, but I don’t want to set everything up from scratch,” then check out gdgoc-uinjkt/init-repo-template. It’s a GitHub template repository that’s ready to go.

🧵 What’s Inside?

This template is carefully curated for clean, consistent project initialization:

.czrc – Configuration file for Commitizen
collaboration_guide.md – Defines commit types, message rules, and branching strategy
code_of_conduct.md – Sets the tone for respectful collaboration
.github/ISSUE_TEMPLATE/ – Issue templates for bug reports and feature requests
.editorconfig – Ensures consistent formatting across IDEs
No language-specific boilerplate – So it's ready for Python, Go, Java, or anything else

🚦 How it Helps

This template removes decision fatigue:

✅ Ready-to-use config – Don’t waste time researching conventions or setting up Commitizen from scratch
📚 Built-in documentation – Teammates know what to do, where to look, and how to contribute
🧑‍🤝‍🧑 Promotes collaboration – Makes expectations clear before the first line of code is written
🏗️ Scales well – From solo projects to large teams, everyone benefits from a consistent setup

🧭 How to Use It

Visit gdgoc-uinjkt/init-repo-template
Click "Use this template" on GitHub
Fill in your repo details and create it
Clone to your machine and start building with best practices in place

🏁 Wrapping Up

Commitizen helps you level up how your team communicates in code. With the right setup—and templates like init-repo-template—you can enforce quality, automate workflows, and build a clean Git history that tells the real story of your project.

Whether you’re working on a solo side project or managing an enterprise-level team, Commitizen brings order to chaos and clarity to collaboration.

Happy committing! 💬✨

🚀 How to Integrate Commitizen (`cz`) into Your NvChad Setup for Better Git Commits

oskhar — Thu, 10 Apr 2025 22:04:42 +0000

✅ Make your Git commit messages clean, consistent, and conventional—right inside Neovim!

When it comes to managing a codebase, well-written commit messages are as important as clean code. They provide context, help with debugging, and assist collaborators (and your future self) in understanding the evolution of your project. That's where tools like Commitizen shine — guiding you through the process of writing conventional, standardized commits with ease.

If you're using NvChad, a modern and minimal Neovim configuration, integrating cz into your workflow can drastically improve your Git hygiene without ever leaving the comfort of your editor.

This guide explores multiple best-practice approaches to integrating the cz CLI into NvChad — from simple key mappings to plugin-powered terminals. Whether you're a minimalist or love your floating terminals, there's a setup here for you.

📌 Prerequisites

Before we begin, make sure you've set up the necessary environment.

✅ 1. Install Node.js and npm

Commitizen is a Node.js-based CLI tool.

node -v
npm -v

If not installed, get Node.js from nodejs.org or use your OS package manager.

✅ 2. Install Commitizen Globally

npm install -g commitizen

Verify the installation with:

cz

This should open the interactive Commitizen prompt in your terminal.

🧠 Why Use Commitizen in Neovim?

Integrating cz directly into Neovim with NvChad offers several advantages:

🧘‍♂️ Editor-focused workflow – no context switching
📋 Standardized commits – enforced structure like Conventional Commits
🚫 Fewer mistakes – no more malformed commit messages
⚡ Speed and efficiency – one keypress to commit

If you’re already using Neovim as your IDE, why not make Git commits as smooth as writing code?

📁 Working with NvChad

NvChad encourages a modular configuration approach. Your custom config lives in:

~/.config/nvim/lua/custom/

You'll mainly edit:

chadrc.lua – main config for mappings, UI tweaks, etc.
mappings.lua – for custom key mappings
plugins/ – for managing additional plugins like toggleterm.nvim

🛠️ Method 1: Lightweight Floating Terminal (Best for Simplicity)

This method uses Neovim's native terminal inside a horizontal split — simple, fast, and dependency-free.

🔧 Setup

Add this function in mappings.lua or chadrc.lua:

local function commitizen_commit()
  vim.cmd("belowright split | resize 15 | terminal cz")
  end

Map the function to a key, like <leader>cz:

  local map = vim.keymap.set
  map("n", "<leader>cz", commitizen_commit, { desc = "Commit using Commitizen" })

✅ Result:

Hit <leader>cz and a split terminal will open at the bottom, running the cz prompt. Super clean and integrates naturally into Neovim.

🧩 Method 2: Enhanced Popup Terminal with ToggleTerm (Best UI)

Want a floating terminal popup with auto-toggle and minimal distractions? Enter toggleterm.nvim.

📦 Step-by-step

Add toggleterm.nvim as a custom plugin in custom/plugins/commitizen.lua:

  return {
    {
      "akinsho/toggleterm.nvim",
        config = function()
          require("toggleterm").setup()

          local Terminal = require("toggleterm.terminal").Terminal
          local cz_term = Terminal:new({
              cmd = "cz",
              hidden = true,
              direction = "float",
              })

      vim.keymap.set("n", "<leader>cz", function()
          cz_term:toggle()
          end, { desc = "Commit with Commitizen" })
        end,
    }
  }

Then import it in custom/plugins/init.lua:

require("custom.plugins.commitizen")

✅ Result:

Press <leader>cz, and a sleek floating terminal opens with cz. One of the best UX enhancements you can add to your Git workflow.

🔁 Method 3: Plain Terminal Split (No Plugin, No Problem)

This method is plugin-free and even more minimalistic.

vim.keymap.set("n", "<leader>cz", function()
    vim.cmd("split | terminal cz")
    end, { desc = "Commitizen simple split" })

✅ Result:

A quick vertical split opens up with cz, perfect if you prefer no extra configuration or dependencies.

🎨 Bonus: Command Palette Integration (NvChad Style)

NvChad includes a command palette-style menu with fuzzy searching. You can create your own custom command to make cz even more accessible.

💡 Add This to `chadrc.lua`:

vim.api.nvim_create_user_command("Commitizen", function()
    vim.cmd("split | terminal cz")
    end, {})

✅ Usage:

Just type :Commitizen in command mode to launch the cz prompt inside a split. Very handy for keyboard-driven users.

🧼 Pro Tip: Prevent Commit Buffers from Lingering

Sometimes, using cz will leave a .git/COMMIT_EDITMSG buffer in Neovim. While harmless, it can clutter your buffer list.

To keep things clean:

Use cz instead of git commit directly.
Set autocommands to close the buffer automatically if needed.
Map <leader>q to close commit message buffers quickly.

📦 Future Enhancements

🤖 Integrate with gitmoji-cli for emoji-powered commits.
🧠 Chain commands to auto-stage, run Commitizen, and push.
🧰 Hook into lazygit.nvim and combine floating tools.
📑 Add commit templates with Conventional Commits + scopes.

🧭 Summary of Methods

Method	Description	Best For
Floating Terminal	Horizontal split terminal with `cz`	Simple, native integration
ToggleTerm Plugin	Popup-style floating terminal	Best UX, clean UI
Plain Terminal Split	Minimal config, vertical split	Fast and dependency-free
Command Palette	Command-mode triggered `cz`	Keyboard-driven workflows

✅ Final Thoughts

You don’t need to leave Neovim to make high-quality, conventional commits. Whether you're team minimalism or love a polished UI, integrating cz into NvChad will save you time, enforce best practices, and make your Git history shine.

This guide offers multiple pathsgg — pick one that fits your workflow or try them all. Either way, your future team (or self) will thank you.

"Domain-Driven Laravel" build great systems that are scalable and powerful

oskhar — Sun, 18 Aug 2024 16:21:57 +0000

In the ever-expanding universe of software development, creating scalable, maintainable, and powerful systems is no small feat. With so many frameworks, tools, and patterns vying for your attention, it's easy to feel like a lost space traveler, orbiting without direction. But fear not, fellow developer! 🌌 The Domain-Driven Laravel repository is here to guide you through the cosmos of RESTful API development, using the Domain-Driven Design (DDD) methodology.

https://github.com/oskhar/domain-driven-laravel

oskhar / domain-driven-laravel

🛸 🔃 A pre-configured Laravel 11.x template crafted to facilitate the development of web applications following Domain-Driven Design (DDD) principles.

Domain-Driven Laravel 🛸 🔃

A robust, scalable, and flexible architecture for developing RESTful APIs with Laravel using Domain-Driven Design (DDD) principles.

📘 Article

Introduction

Laravel is an excellent framework for building Powerfull Apps, offering a rich set of features and a clean syntax. However, as projects grow in complexity, it's easy for the codebase to become unmanageable. The absence of a clear architectural pattern can lead to a mix of responsibilities, making the code harder to maintain and scale.

This repository presents a way to structure Laravel projects using Domain-Driven Design (DDD) principles, allowing for better organization, scalability, and separation of concerns. The approach showcased here is inspired by best practices and aims to solve real-world challenges in a practical and maintainable way.

The goal is to provide a solid foundation for building Laravel applications that are.

🧩 Easy to Understand. A well-organized codebase with clear boundaries.
🛠️ Maintainable. Follow…

View on GitHub

In this article, we’ll explore the galaxy of this remarkable Laravel package, uncover its unique features, and see why it's perfect for developers looking to build sophisticated systems. Buckle up, space cowboy, because we’re about to launch! 🚀

directory structure: https://github.com/oskhar/domain-driven-laravel/blob/main/docs/project-structure.md

What Is Domain-Driven Laravel?

"Domain-Driven Laravel 🛸 🔃" is a structured approach to building RESTful APIs using Laravel, centered around the principles of Domain-Driven Design (DDD). This package allows you to structure your application logically by grouping related business logic into domains, making your system easier to scale and maintain.

By leveraging Laravel’s robust architecture with the organizational power of DDD, this repository helps developers create well-organized APIs that are as efficient as they are powerful.

Why Domain-Driven Design?

Domain-Driven Design provides a clear structure for separating concerns and organizing your application into manageable, understandable parts. It focuses on defining the core domain and domain logic (the heart of your business logic) and keeps your application modular.

Imagine having your system organized like planets orbiting a star, each with a well-defined purpose and connection to the larger system. With DDD, you’ll have domains such as User Management, Product Management, and more, each managing its own gravitational pull in the API ecosystem.

The real magic of "Domain-Driven Laravel 🛸 🔃" is in its thoughtful implementation of these concepts, transforming Laravel into a well-oiled machine of interconnected domains. You can now build applications that are scalable and ready for the complexities of the real world.

The Power of Error Handling: Laughing Through the Cosmos 🤖

If you’re like most developers, you’ve encountered your fair share of error messages. But have you ever had an error handler that insults you for making a mistake? Welcome to the world of "Domain-Driven Laravel 🛸 🔃", where error handling is not just functional—it’s personal and hilarious!

This repo offers a built-in error-handling mechanism that not only returns the expected HTTP status codes but also scolds you for making mistakes. Let’s break down some of these responses:

$exceptions->render(
    fn(QueryException $exception, $request) => ($response)(
        APIResponseData::from([
            "status" => false,
            "errors" => [
                "Bro wrote the wrong database query. Backend skills issue.",
                $exception->getMessage()
            ]
        ]),
        APIStatusEnum::INTERNAL_SERVER_ERROR
    )
);

The moment you make a bad database query, you’ll be greeted with a response like:

"Bro wrote the wrong database query. Backend skills issue."

Instead of a typical, dry error message, the system nudges you to improve your backend skills—sometimes with a bit of attitude!

Other responses include:

Array Structure Gone Wrong:

"Ayyo, looks like your backend messed up the array structure."

Bad Method Call:

"Are you sure backend bro? The method you called doesn't exist."

Undefined Exception:
```
"Your backend is dumb, bro."
```

This unique approach not only provides you with helpful information but adds a fun twist to your debugging experience. It turns those dreaded errors into moments of levity, reminding you that even in the vastness of code, a little humor can go a long way.

Response Structure.

Thanks to the well-defined structure of the API response, all errors, including these personalized ones, will follow a consistent format. The APIResponseData class ensures that the response is structured like this:

class APIResponseData extends Data
{
    public function __construct(
        readonly ?bool $status = true,
        readonly ?string $message,
        readonly mixed $data = null,
        /** @var array<string> */
        readonly ?array $errors,
        readonly ?PaginationData $pagination,
        readonly ?APIMetaData $meta,
    ) {
    }
}

Here’s how a 500 Internal Server Error might look:

// Example 500 Internal Server Error
{
    "status": false,
    "message": "Galactic disruption. An unexpected cosmic event occurred!",
    "errors": [
        "Bro wrote the wrong database query. Backend skills issue",
        "{{ Query error messages specifically }}"
    ],
    "meta": {
        "request_id": "string",
        "response_size": "integer|byte"
    }
}

This structure provides clarity and consistency, ensuring that every response, whether success or failure, is predictable and easy to handle on the client side.

Default Messages: Cosmic Wisdom 🌠

Another shining feature of this repository is the default message handling for API responses. If you forget to set a message on your response, you won't just get a generic fallback—you’ll get a galactic-themed message that makes your API feel like a trip through the stars.

Here’s a sample of the default messages:

200 SUCCESS: "Success! Your request has safely landed back to Earth."
201 CREATED: "New entity launched into the cosmos."
400 BAD_REQUEST: "Your request veered off course and couldn't escape Earth's gravity!"
401 UNAUTHORIZED: "Your credentials don't pass the cosmic gatekeeper!"
404 NOT_FOUND: "The data you're seeking is beyond the bounds of space!"
500 INTERNAL_SERVER_ERROR: "Galactic disruption. An unexpected cosmic event occurred!"

These thematic responses don’t just provide a fun flavor to your API—they also make it clearer to clients and users what’s happening under the hood.

For example, if your request hits a 404, instead of a boring "Not Found" message, you’ll receive a cosmic-themed error:

"The data you're seeking is beyond the bounds of space!"

This approach not only enriches the developer experience but also makes the API more user-friendly. Your clients and users will enjoy these little touches of humor and personality.

Going Beyond: What Else Makes This Repository Stellar? 💫

"Domain-Driven Laravel 🛸 🔃" isn't just about humor and cosmic messages. It's a fully fleshed-out package that makes it easier to manage your Laravel applications using DDD principles. Let’s take a look at some of the other key features:

1. Modular Domain Design.

With a clean and modular architecture, you can easily organize your application into domains, each with its own logic and responsibility. This separation allows for better scaling, testing, and maintenance.

2. Built-in API Response Management.

Handling API responses is a breeze with a consistent structure that ensures all responses are formatted correctly. Whether you’re returning success, error, or validation messages, the built-in API response handler will make sure everything is in its right place.

3. Error Handling that Learns.

While the humorous error handling adds personality, it also comes with a solid system that tracks and logs exceptions in a way that helps you debug and improve your code.

4. Advanced Middleware.

The repository includes advanced middleware implementations that ensure all parts of your application are in sync with the domain rules and API structure. With these middleware hooks, you can ensure that your application always behaves as expected.

5. Integration with Spatie's Packages.

Leverage the power of Spatie’s robust Laravel packages for roles, permissions, and data handling. This repo comes with pre-configured support for Spatie’s tools, giving you the best of both worlds: the organization of DDD and the strength of Laravel’s best packages.

Simple Usage: Focus on Domain Actions 🛠️

When working with the repository, simplicity is key. The goal is for developers to focus purely on domain actions without worrying about infrastructure concerns. This clear separation of responsibilities ensures that each domain handles its own business logic while leaving shared services and external integrations to other layers.

1. Stay Focused on Domain Actions.

In this structure, all core logic related to a specific domain is encapsulated in Actions. You don’t need to think about cross-domain interactions or infrastructure concerns—just focus on building the actions that power your domain. For example, an action like CreateUserAction lives entirely within the User domain and manages user creation. You can call this action from a controller or another action, keeping your code concise and easy to manage.

namespace Domain\User\Actions;

use Domain\User\Models\User;
use Domain\User\Data\UserData;

class CreateUserAction
{
    public function execute(UserData $data): User
    {
        return User::create($data);
    }
}

This straightforward action does its job without needing to handle infrastructure-level details like logging, caching, or external API calls. Those concerns are dealt with in the Infrastructure layer or the Shared domain, keeping your actions clean and single-focused.

2. Shared Domain for Cross-Cutting Concerns.

Any service that spans across multiple domains, such as authentication, logging, or notifications, can be placed in the Shared domain. This prevents domain entanglement and ensures that the logic stays modular and focused.

For example, a notification service can live in the Shared domain, allowing any domain to trigger notifications without duplicating code.

namespace Domain\Shared\Services;

class NotificationService
{
    public function sendNotification(UserData $user, string $message): bool
    {
        // Logic for sending notifications
    }
}

Any domain that needs to notify users can simply call this service, ensuring that the NotificationService is consistent across the application.

3. Infrastructure for External Integrations.

The Infrastructure layer handles external services and integrations. This includes third-party APIs, payment gateways, or database configurations. By keeping external integrations here, your domain actions remain focused on business logic without worrying about how the external world works.

For instance, a payment gateway service could be handled in Infrastructure, keeping payment logic separate from core domain actions.

namespace Infrastructure\Services;

class PaymentGatewayService
{
    public function processPayment(PaymentDetailsData $details): mixed
    {
        // Payment processing logic
    }
}

With this structure, domain actions can call on external services when needed, but the bulk of the integration code is abstracted away, keeping your business logic clean and independent.

4. Flexibility with Interfaces.

To enhance the repository's flexibility and error prevention, developers who are comfortable using interfaces can incorporate a dedicated Interfaces folder. This addition provides a structured way to manage potential changes, such as migrations or dependency removals, without impacting the core functionality. The minimalist design of this repository ensures that it remains adaptable to various development needs, and the use of interfaces aligns with this principle by offering a safeguard against unforeseen changes.

app
├── Console                     # Custom Artisan commands
├── Domain                      # Core domain logic and business rules
├── Infrastructure              # Infrastructure-related code
└── Interfaces                  # Additional Folder

This approach allows developers to define contracts for their actions, services, or any other components that may evolve over time, ensuring that the code remains stable and maintainable across different stages of development.

5. No Domain Interference.

One of the core principles of "Domain-Driven Laravel 🛸 🔃" is that each domain should remain isolated from others. Domains should not interfere with each other’s logic or responsibilities. If multiple domains need to share services or data, those services should either be abstracted into the Shared domain or handled in Infrastructure.

This ensures that no domain unintentionally “leaks” logic or affects the behavior of another. It makes your codebase easier to maintain and scale as each domain evolves independently.

Conclusion: Take Your Laravel Development to the Stars 🌌

If you’re ready to build Laravel applications that are not only scalable and powerful but also fun to work with, "Domain-Driven Laravel 🛸 🔃" is the repository for you. It combines the elegance of Domain-Driven Design with Laravel's strength, all while adding a dash of cosmic humor 💀

Whether you’re a seasoned developer or just getting started with DDD, this package will help you organize your code, streamline your APIs, and provide a delightful development experience.

So what are you waiting for? Head over to the Domain-Driven Laravel 🛸 🔃 repository, and start building systems that are out of this world!

May your code always compile, and your APIs always return a 200! 🚀✨

Forem: oskhar

🚀 Commitizen: Making Git Commits the Right Way

GDGoC-UINJKT / init-repo-template

🚀 Kickstart your next project with a clean, consistent, and collaborative-ready repo template — zero fuss, maximum clarity.

🚀 init-repo-template

Why this template?

What’s included ✨

Getting started

1. Clone the template

2. Read the collaboration guide

3. Initialize your repository

🧠 Why Commit Messages Matter

✨ What is Commitizen, Really?

🔍 Where Did Commitizen Come From?

💡 Why Use Commitizen?

Some benefits in more detail:

⚙️ How to Get Started

1. 📦 Installation

2. 📐 Choose an Adapter

3. 🖊️ Start Committing

🧭 Beyond Basics: Making Commitizen Part of the Culture

Best practices to help it stick:

🛠️ A Real-World Template You Can Use Today

🧵 What’s Inside?

🚦 How it Helps

🧭 How to Use It

🏁 Wrapping Up

🚀 How to Integrate Commitizen (`cz`) into Your NvChad Setup for Better Git Commits

📌 Prerequisites

✅ 1. Install Node.js and npm

✅ 2. Install Commitizen Globally

🧠 Why Use Commitizen in Neovim?

📁 Working with NvChad

🛠️ Method 1: Lightweight Floating Terminal (Best for Simplicity)

🔧 Setup

✅ Result:

🧩 Method 2: Enhanced Popup Terminal with ToggleTerm (Best UI)

📦 Step-by-step

✅ Result:

🔁 Method 3: Plain Terminal Split (No Plugin, No Problem)

✅ Result:

🎨 Bonus: Command Palette Integration (NvChad Style)

💡 Add This to chadrc.lua:

✅ Usage:

🧼 Pro Tip: Prevent Commit Buffers from Lingering

📦 Future Enhancements

🧭 Summary of Methods

✅ Final Thoughts

"Domain-Driven Laravel" build great systems that are scalable and powerful

oskhar / domain-driven-laravel

🛸 🔃 A pre-configured Laravel 11.x template crafted to facilitate the development of web applications following Domain-Driven Design (DDD) principles.

Domain-Driven Laravel 🛸 🔃

Introduction

What Is Domain-Driven Laravel?

Why Domain-Driven Design?

The Power of Error Handling: Laughing Through the Cosmos 🤖

Response Structure.

Default Messages: Cosmic Wisdom 🌠

Going Beyond: What Else Makes This Repository Stellar? 💫

1. Modular Domain Design.

2. Built-in API Response Management.

3. Error Handling that Learns.

4. Advanced Middleware.

5. Integration with Spatie's Packages.

Simple Usage: Focus on Domain Actions 🛠️

1. Stay Focused on Domain Actions.

2. Shared Domain for Cross-Cutting Concerns.

3. Infrastructure for External Integrations.

4. Flexibility with Interfaces.

5. No Domain Interference.

Conclusion: Take Your Laravel Development to the Stars 🌌

💡 Add This to `chadrc.lua`: