DEV Community: arminbro

Keep Your Repo Clean with Repo Pruner

arminbro — Sun, 17 Nov 2024 22:11:48 +0000

Hey devs! 👋

If you've ever worked on a project with a large team, you know how quickly branches can pile up. After months of development, dozens (or even hundreds) of branches end up sitting around. With time, it becomes a challenge to know what’s active, what’s abandoned, and what’s still needed. That's where Repo Pruner comes in.

I've built Repo Pruner as a GitHub Action to help solve this very issue — keeping repos clean and manageable, even when teams grow and activity ramps up. It automatically detects branches that have been inactive for a configurable amount of time and summarizes them for the team to review. It’s designed to help big teams avoid the clutter that comes with inactive branches, especially when we all forget to clean up after ourselves (guilty as charged 🙋‍♂️).

The Problem

In any project where you have a lot of team members, you’re going to have a lot of branches. Some people are diligent about deleting their old branches after merges or feature work. But let's be honest — in the rush to get things done, old branches often get overlooked. They start piling up, and eventually, no one knows which branches are safe to delete and which might still be needed. This creates a lot of confusion and makes it harder for the whole team to find what they need.

How Repo Pruner Helps

Repo Pruner runs as a scheduled GitHub Action, and here's what it does:

Scans branches to find those that have been inactive beyond a certain threshold.
Ignores protected branches (so nothing critical gets pruned).
Creates a new summary issue listing all the branches that are candidates for deletion.
Closes any previous summary issues to keep things fresh and organized.

This way, the team gets a new, updated overview of all the branches that have been inactive each time the workflow runs. The summary issue is easy to read and includes all the important details — branch name, last commit date, merged status, any associated pull request, and a chance for team members to mark each branch as Keep or Delete.

Why Close and Reopen Issues?

I wanted Repo Pruner to work in a way that doesn’t clutter up the issues page. Instead of endlessly updating one issue or spamming new issues every time it runs, Repo Pruner keeps it neat. It closes the previous issue and creates a fresh new one with up-to-date information. This way, every time you look at it, you’re seeing the latest status. And if anyone needs to look back at history, the old issues are still there, closed but preserved, so you can trace what’s been done.

How to Use It

It’s super simple to get started. Here’s how you can add Repo Pruner to your workflow:

name: "Run Repo Pruner"
on:
  schedule:
    - cron: '0 0 1 * *' # Runs once a month - At 00:00 on day-of-month 1.
  workflow_dispatch:

jobs:
  repo-pruner:
    runs-on: ubuntu-latest
    steps:
      - name: Run Repo Pruner
        uses: arminbro/repo-pruner@v2.1.17
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          inactive_days: 30

This workflow will run Repo Pruner every month and provide you with an overview of branches that have been inactive for more than 30 days.

Who Is It For?

If your repo only has a few branches, you might not need this. But if you’re working with a large team and multiple feature branches, stale branches can become a serious pain point. Repo Pruner is for teams that want to keep their repos tidy without spending hours manually checking branch activity. It’s perfect for big projects, especially those with frequent contributors who don’t always remember to clean up.

Final Thoughts

I’m all about making things easier for dev teams. Repo Pruner is one of those tools that makes the "housekeeping" part of development just a bit more manageable. Give it a try, and hopefully, it helps keep your repo a little more organized, too. If you use it or have suggestions for how it could be improved, feel free to drop me a line. Contributions and feedback are always welcome!

You can find Repo Pruner here: GitHub Marketplace Link

Happy pruning! 🌿

Armin

Would love to hear how you manage stale branches in your teams. Drop your thoughts in the comments below!

WordHoop: A Lightweight Word Game Built with SolidJS

arminbro — Wed, 23 Oct 2024 03:24:22 +0000

As developers, we’re always looking for ways to optimize our code, reduce bloat, and deliver the best experience possible for users. That’s exactly what I set out to do when I created WordHoop, a daily word game packed with fun yet incredibly lightweight.

The Frontend Stack

SolidJS: A reactive framework offering fine-grained reactivity with a smaller bundle size than React, making it ideal for performance-focused web apps.
Solid Transition Group: To help apply animations when children elements enter or leave the DOM throughout the game.
Tailwind CSS: A utility-first CSS framework that allowed me to efficiently build a clean and responsive UI without adding unnecessary weight, keeping the styles both minimal and scalable.

Keeping it Small and Fast

One of the things I’m most proud of is that WordHoop is under 100KB on the initial page load! This helps achieve perfect 100% PageSpeed scores across the board.

Try it Out!

WordHoop is simple to play but offers a daily word unscrambling challenge that keeps players returning. It’s a great way to take a quick break while exercising your brain.

I’d love to hear your thoughts on the game or any tips you might have for further optimization. You can play it here: https://www.wordhoop.com.

Follow me:

Generate React CLI

arminbro — Mon, 25 Nov 2019 00:45:53 +0000

I enjoy working on React projects, but one thing that gets in the way of staying productive is having to write or copy boilerplate code repetitively when creating new components.

Create React App and Gatsby do a great job of initializing new projects, setting up the development environment, and optimizing the app for production use. Still, they don't have a way to generate new components similar to what Angular CLI offers, and that's because they both try to stay as non-opinionated as possible and allow the developer to make those decisions. One example would be grouping by features vs. grouping by file type when creating components.

Generate React CLI, on the other hand, currently focuses on one thing, and that's generating new components by running a simple command. It also doesn't care if you run it in an existing CRA, Gatsby, or a custom React project you built on your own.

It does, however, have an opinion on how component files are structured. It follows grouping by feature, and that's because we believe when you look at a component, you should see all of its corresponding files (i.e., stylesheet, test, and component) under one folder with the component name. We feel this approach provides a better developer experience.

A great Medium post on how to structure a React project: "The 100% correct way to structure a React app (or why there’s no such thing)" by David Gilbertson

How to use Generate React CLI

Before you get started, make sure to have Node >= 10.x and NPM >= 6.x installed on your machine.

You can run it using npx like this:

  npx generate-react-cli component Box

(npx is a package runner tool that comes with npm 5.2+)

Config File

When you run GRC within your project the first time, it will ask you a series of questions to customize the cli for your project needs (this will create a "generate-react-cli.json" config file).

Example of the generate-react-cli.json config file:

{
  "usesTypeScript": false,
  "usesCssModule": true,
  "cssPreprocessor": "scss",
  "testLibrary": "Testing Library",
  "component": {
    "default": {
      "path": "src/components",
      "withLazy": false,
      "withStory": false,
      "withStyle": true,
      "withTest": true
    }
  }
}

Generate Components

  npx generate-react-cli component Box

This command will create a folder with your component name within your default (e.g. src/components) directory, and its corresponding files.

Example of the component files structure:

|-- /src
    |-- /components
        |-- /Box
            |-- Box.js
            |-- Box.css
            |-- Box.test.js

Options

You can also override some of the GRC component config rules using one-off commands. So for example, let's say you have set withTest to be true in the component.default property. You can override it like this:

  npx generate-react-cli component Box --withTest=false

Or vice versa, if you have set withTest to be false you can do this:

  npx generate-react-cli component Box --withTest=true

Otherwise, if you don't pass any options, it will just use the default values that you have set in the GRC config file under component.default.

Options	Description	Value Type	Default Value
--path	Value of the path where you want the component to be generated in (e.g. src/components).	String	`component.default.path`
--type	You can pass a custom component type that you have configured in the GRC config file that has its own set of component config rules. Read more about custom component types.	String	`component.default`
--withLazy	Creates a corresponding lazy file (a file that lazy-loads your component out of the box and enables code splitting) with this component.	Boolean	`component.default.withLazy`
--withStory	Creates a corresponding (storybook) story file with this component.	Boolean	`component.default.withStory`
--withStyle	Creates a corresponding stylesheet file with this component.	Boolean	`component.default.withStyle`
--withTest	Creates a corresponding test file with this component.	Boolean	`component.default.withTest`

Custom component types:

By default, GRC will use the component.default configuration rules when running the component command out of the box.

What if you wanted to generate other types of components that have their own set of config rules (e.g., page or layout)?

You can do so by extending the generate-react-cli.json config file like this.

{
  "usesTypeScript": false,
  "usesCssModule": true,
  "cssPreprocessor": "scss",
  "testLibrary": "Testing Library",
  "component": {
    "default": {
      "path": "src/components",
      "withLazy": false,
      "withStory": false,
      "withStyle": true,
      "withTest": true
    },
    "page": {
      "path": "src/pages",
      "withLazy": true,
      "withStory": false,
      "withStyle": true,
      "withTest": true
    },
    "layout": {
      "path": "src/layout",
      "withLazy": false,
      "withStory": false,
      "withStyle": false,
      "withTest": true
    }
  }
}

Now you can generate a component with your custom component types like this:

  npx generate-react-cli component HomePage --type=page

  npx generate-react-cli component BoxLayout --type=layout

You can also pass the same options to your custom component types as you would for the default component type.

Custom component templates

You can also create your own custom templates that GRC can use instead of the built-in templates that come with it. We hope this will provide more flexibility for your components that you want to generate.

There is an optional customTemplates object that you can pass to the component.default or any of your custom component types within your generate-react-cli.json config file.

Example of the `customTemplates` object:

"customTemplates": {
  "component": "templates/TemplateName.js",
  "lazy":  "templates/TemplateName.lazy.js",
  "story":  "templates/TemplateName.story.js",
  "style": "templates/TemplateName.style.scss",
  "test":  "templates/TemplateName.test.js"
},

The keys represent the type of file, and the values are the paths that point to where your custom template lives in your project/system. Please note the TemplateName keyword in the template filename. GRC will use this keyword and replace it with your component name as the filename.

Example of using the `customTemplates` object within your generate-react-cli.json config file:

{
  "usesTypeScript": false,
  "usesCssModule": true,
  "cssPreprocessor": "scss",
  "testLibrary": "Testing Library",
  "component": {
    "default": {
      "customTemplates": {
        "component": "templates/component/TemplateName.js",
        "style": "templates/component/TemplateName.style.scss",
        "test": "templates/component/TemplateName.test.js"
      },
      "path": "src/components",
      "withStyle": true,
      "withTest": true,
      "withStory": true,
      "withLazy": false
    },
    "page": {
      "customTemplates": {
        "test": "templates/page/TemplateName.test.js"
      },
      "path": "src/pages",
      "withLazy": true,
      "withStory": false,
      "withStyle": true,
      "withTest": true
    }
  }
}

Notice in the page.customTemplates that we only specified the test custom template type. That's because all the custom template types are optional. If you don't set the other types, GRC will default to using the built-in templates it comes with.

Example of a custom component template file:

// templates/component/TemplateName.js

import React from 'react';
import styles from './TemplateName.module.css';

const TemplateName = () => (
  <div className={styles.TemplateName} data-testid="TemplateName">
    <h1>TemplateName component</h1>
  </div>
);

export default TemplateName;

Important - Make sure to use the TemplateName keyword in your templates as well. GRC will also use this keyword to replace it with your component name.

Example of a custom test template file:

// templates/component/TemplateName.test.js

import React from 'react';
import ReactDOM from 'react-dom';
import TemplateName from './TemplateName';

it('It should mount', () => {
  const div = document.createElement('div');
  ReactDOM.render(<TemplateName />, div);
  ReactDOM.unmountComponentAtNode(div);
});

Custom component files

GRC comes with corresponding built-in files for a given component if you need them (i.e., withStyle, withTest, withStory, and withLazy).

What if you wanted to add custom files of your own?

For example, let's say you wanted to add an index.js file for each component, so you don't have to add the additional component name with each import (i.e., import Box from './components/Box' instead of import Box from './components/Box/Box').

Or maybe you need an additional style file for your component stories.

You can do so by editing your generate-react-cli.json config file like so.

{
  "usesTypeScript": false,
  "usesCssModule": false,
  "cssPreprocessor": "css",
  "testLibrary": "Testing Library",
  "component": {
    "default": {
      "path": "src/components",
      "withStyle": true,
      "withTest": true,
      "withStory": true,
      "withLazy": false,
      "withIndex": true,
      "withStoryStyle": true,
      "customTemplates": {
        "index": "templates/default/index.js",
        "storyStyle": "templates/default/TemplateName.stories.css"
      }
    }
  }
}

// templates/default/index.js

export { default } from './TemplateName';

/* templates/default/TemplateName.stories.css */

.TemplateName {}

In this case, we added a withIndex & withStoryStyle to the component.default. Note: You can add custom files to any of your custom component types.

You should also see that we added index and storyStyle to our customTemplates object. That's because custom files require custom templates. Otherwise, you will get an error when you generate a component.

Also, we used the TemplateName keyword for the storyStyle custom file. GRC will generate this corresponding file and replace TemplateName with the component name.

That's it. I hope GRC helps you stay productive in your React projects.

✌,
Armin