DEV Community: Sheng-Lin Yang

Release my PR for the project Bifrost

Sheng-Lin Yang — Sat, 13 Dec 2025 00:26:56 +0000

Final Reflection – Implementing the "Enable/Disable API Key" Feature in Bifrost

When I first started working on this issue, I believed it would be a simple front-end modification — just adding a small component and a few backend adjustments. However, as I explored the project more deeply, I realized it was actually a full-stack feature that involved the frontend, backend, and database layers.

Bifrost is a large-scale, high-performance AI gateway written primarily in Go, without using any backend web frameworks. This gave me a great opportunity to learn how a production-grade system is architected directly in Go. On the frontend side, the project uses Next.js with Shadcn UI, which were both relatively new technologies for me and became an excellent learning experience.

Technical Implementation

Frontend:
In ui/app/workspace/providers/views/modelProviderKeysTableView.tsx, I implemented the feature using the existing Switch component to let users enable or disable their API keys instead of deleting them. This small UI change significantly improves user experience by allowing temporary control over keys.

Backend:
I updated multiple backend files to extend the data schema and handle the new enabled field in logic.

Core:
In core/bifrost.go, I added logic to ensure requests only use enabled keys, skipping any that are disabled.

Database:
In framework/configstore/migrations.go, I wrote a manual migration script to add the new enabled column to the keys table and set its default value to true. This ensured data consistency without relying on any framework-level ORM migration tools.

Collaboration and Review Process

After pushing my pull request, I followed the automated feedback from CodeRabbitAI and the advice from other contributors. Their suggestions helped me spot missing pieces, follow the repository's coding conventions, and refine my migration logic. These automated tools and community interactions reduced communication delays and improved both my workflow and code quality.

Conclusion

Throughout this contribution, I learned how powerful Go can be for backend, CLI, and microservice development. Working on Bifrost taught me how to design and implement web application features without relying on frameworks — managing SQL migrations manually and integrating logic across the full stack.

This was a valuable experience that strengthened my understanding of full-stack development, open-source collaboration, and how modern teams maintain high-quality production systems.

Progressing in Bifrost project

Sheng-Lin Yang — Fri, 12 Dec 2025 23:23:33 +0000

In the issue 831 of Bifrost

make dev starts full stack (frontend:3000 + backend:8080)
http://localhost:3000/workspace/providers verifies API Key page
Fork + feature branch: git checkout -b 11-17-feat-option-disable-key

ui/app/workspace/providers/views/modelProviderKeysTableView.tsx:

<TableCell>
  <Switch
    checked={isKeyEnabled}
    disabled={!hasUpdateProviderAccess}
    onCheckedChange={(checked) => {
      updateProvider({
        ...provider,
        keys: provider.keys.map((k, i) =>
          i === index ? { ...k, enabled: checked } : k
        ),
      })
        .unwrap()
        .then(() => {
          toast.success(`Key ${checked ? "enabled" : "disabled"} successfully`);
        })
        .catch((err) => {
          toast.error("Failed to update key", { description: getErrorMessage(err) });
        });
    }}
  />
</TableCell>

→ This is a table for the API Key. I have done about the UI and the type of schema in front-end.

framework/configstore/tables/key.go:

type TableKey struct {
  Enabled    *bool     `gorm:"default:true" json:"enabled,omitempty"`
}

if k.Enabled == nil {
  enabled := true // DB default
  k.Enabled = &enabled
}
(In functions of BeforeSave and AfterFind)

→ SQLite schema，no enabled column; migration needed.

core/bifrost.go:

// Skip disabled keys (default enabled when nil)
if k.Enabled != nil && !*k.Enabled {
  continue
}

→ The logic of provider selector

The code in back-end seems that it could be able to set up as enabled or disabled for front-end.

However, the workflow and the codeRabbit on GitHub was kept telling me there were something better to improve(like: migration the data column manually, add log in files core/changelog.md and transports/changelog.md) for the issue in the project. Also, I got the message about the data should migrate manually so I have to write the code in framework/configstore/migrations.go.

if err := migrationAddPluginVersionColumn(ctx, db); err != nil {
  return err
}

// migrationAddEnabledColumnToKeyTable adds the enabled column to the config_keys table
func migrationAddEnabledColumnToKeyTable(ctx context.Context, db *gorm.DB) error {
    m := migrator.New(db, migrator.DefaultOptions, []*migrator.Migration{{
        ID: "add_enabled_column_to_key_table",
        Migrate: func(tx *gorm.DB) error {
            tx = tx.WithContext(ctx)
            mg := tx.Migrator()

            // Check if column already exists
            if !mg.HasColumn(&tables.TableKey{}, "enabled") {
                // Add the column
                if err := mg.AddColumn(&tables.TableKey{}, "enabled"); err != nil {
                    return fmt.Errorf("failed to add enabled column: %w", err)
                }

            }
            // Set default = true for existing rows
            if err := tx.Exec("UPDATE config_keys SET enabled = TRUE WHERE enabled IS NULL").Error; err != nil {
                return fmt.Errorf("failed to backfill enabled column: %w", err)
            }

            return nil
        },
        Rollback: func(tx *gorm.DB) error {
            tx = tx.WithContext(ctx)
            mg := tx.Migrator()

            if mg.HasColumn(&tables.TableKey{}, "enabled") {
                if err := mg.DropColumn(&tables.TableKey{}, "enabled"); err != nil {
                    return fmt.Errorf("failed to drop enabled column: %w", err)
                }
            }

            return nil
        },
    }})

    if err := m.Migrate(); err != nil {
        return fmt.Errorf("error running enabled column migration: %s", err.Error())
    }
    return nil
}

Conclusion:
Since working on this project that I have been followed Coderabbitai and with other contributors in something that I may miss in the whole progressing.

Planning to solve a new larger project

Sheng-Lin Yang — Fri, 12 Dec 2025 14:09:30 +0000

I chose the project with Bifrost because the description as Fastest LLM gateway (50x faster than LiteLLM) with adaptive load balancer, cluster mode, guardrails, 1000+ models support & <100 µs overhead at 5k RPS.

The current issue:
In the Bifrost Web UI, API key management only supports "add/delete." When users want to pause a key (keep the configuration but stop using it), they can only delete and recreate it, which leads to weak User Experience.

In this issue that the solution may be:
Frontend: Toggle Switch + Disabled status display (ui/)
Backend: Add Enabled: *bool field, HTTP handler filtering (transports/bifrost-http/)
Core: Provider selector skips disabled keys (core/bifrost.go)
Database: Configstore schema migration (framework/configstore/)
Real-time sync: Toggle takes effect immediately, no restart needed

I have worked on multiple open-source CLI tools (including LLM integrations) and WebSocket websites, but this is my first challenge:

High-performance Go + Next.js architecture (68% Go + 23% TypeScript)
Production-grade LLM gateway (1300+ stars, actively maintained)
Starting from the frontend and then gradually going deeper into the backend core.

Learning Value:

Go pure HTTP handler implementation (core/)
Next.js + Go backend integration patterns
Bifrost configstore architecture (framework/configstore)

Conclusion:
It is not only adjust the User Interface on the web page but also need to modify the core code.

Release my cli tool on npm

Sheng-Lin Yang — Fri, 21 Nov 2025 21:16:09 +0000

For my TypeScript CLI project using pnpm, I chose npm as the package registry and release tool.

Reason: npm is the standard package registry for Node.js and TypeScript projects, widely used and supported.
Link: npm repo for repo-snapshot

By releasing via npm, my CLI tool becomes easily installable by developers globally, either with npm or pnpm.

Before publishing, I made several changes to ensure the project would work smoothly:

README.md – Updated installation instructions, usage examples, and added both npm and pnpm instructions.
package.json –

Added "main" field for entry point
Added "files" field to include only compiled files
Added "repository" information
1. tsconfig.json – Adjusted output settings to generate proper compiled JavaScript for npm.

These changes made the project more user-friendly and compatible with npm’s publishing requirements.

Here is the detailed step-by-step process I followed:

Step 1 – Register npm Account

Created an account on npm
Verified my email

Step 2 – Prepare Git Repository

Pushed the latest code to GitHub
Used git tag to mark release versions, e.g., git tag v0.9.0 and git push --tags

Step 3 – Publish to npm

# Log in to npm
npm login

# Publish the package
npm publish --access public

After this, my CLI tool was publicly available.

However, I wanted every new release to automatically publish to npm. I implemented CD using GitHub Actions:

Steps:

Generate npm Access Token

npm Access Tokens
1. Add Secret in GitHub
Repository → Settings → Secrets and variables → Actions → New Repository Secret
Name: NPM_TOKEN
Secret: Copy the npm token
1. Create GitHub Actions Workflow
Path: .github/workflows/npm-publish.yml
Use example code from npm documentation
Customize branch, version, and other settings

Example snippet of workflow:

name: npm publish

on:
  push:
    tags:
      - 'v*.*.*'  # or 'v*'

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: '18'
          registry-url: 'https://registry.npmjs.org'
      - run: npm ci
      - run: npm run build
      - run: npm publish
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

This setup ensures that any new tag automatically triggers a release.

Even though I tested the installation myself, I wanted a fresh perspective:

I asked a partner unfamiliar with my project to follow the README instructions.
Observations:

Initially, they missed the difference between npm and pnpm.
They tried installing without nvm (required for npm but not for pnpm).
- Fixes:

Clarified installation instructions in README
Added separate examples for npm and pnpm
Ensured users understand how to run the CLI immediately after install

This session was very useful to make the tool more beginner-friendly.

So the users can now install the tool globally:

Using npm:

npm install -g repo-snapshot
repo-snapshot --help

Using pnpm:

pnpm add -g repo-snapshot
repo-snapshot --help

Conclusion

Publishing repo-snapshot taught me:

How to prepare a TypeScript CLI for npm release
How to automate releases with GitHub Actions
How to test usability for external users
How to document clear installation instructions

Seeing my project live on npm and available for anyone to download was a rewarding experience and a major milestone for my CLI development journey.

Combine retry feature and logging in second issue

Sheng-Lin Yang — Fri, 21 Nov 2025 19:56:10 +0000

Repository: CLImanga
Issue: Check chapterImage download response for CLImanga
PR: fix: retry download if failed

During the development of CLImanga, I noticed a small but impactful issue:
When the program tried to download a manga image, if the download failed (for example due to network issues or a temporary server problem), the program would stop immediately and not attempt to retry.

This made the download process unreliable, especially when handling multiple chapters or large manga series.

The goal of this PR was to implement a retry mechanism to improve reliability and provide visibility into download attempts using the custom logging system I implemented in the previous PR.

The retry mechanism needed to satisfy the following:

Attempt downloads multiple times (set a maximum of 5 retries) if an error occurs.
Log each failed attempt with details such as attempt number, URL, and error reason.
Include a small delay between retries to avoid overwhelming the server (time.Sleep).
Fail gracefully if all attempts are exhausted, returning a descriptive error.
Integrate with the existing logging system so all attempts are persisted in logs/latest.log.

I improved the downloadFile function handles the download logic with retry support:

func downloadFile(url, path string) error {
    const maxRetries = 5
    var err error
    for attempt := 0; attempt < maxRetries; attempt++ {
        err = func() error {
            resp, err := http.Get(url)
            if err != nil {
                return err
            }
            defer resp.Body.Close()

            if resp.StatusCode != http.StatusOK {
                return fmt.Errorf("bad status: %s", resp.Status)
            }

            outFile, err := os.Create(path)
            if err != nil {
                return err
            }
            defer outFile.Close()

            _, err = io.Copy(outFile, resp.Body)
            return err
        }()
        if err == nil {
            return nil // success
        }
        logger.Error.Printf("Attempt %d: Failed to download %s: %v", attempt+1, url, err)
        time.Sleep(time.Second * 4) // If failed, wait and retry
    }

    // If all attempts fail, return the last error
    return fmt.Errorf("failed to download file from %s after %d attempts: %v", url, maxRetries, err)
}

Key Design Decisions

Anonymous function for each attempt: Ensures that each retry has its own scope for error handling and resource cleanup.
Logging with attempt number: Makes it easy to track how many retries occurred and why.
Delay using time.Sleep: Reduces risk of overwhelming the server or triggering rate limits.
MaxRetries constant: Prevents infinite loops and allows easy adjustment.

After I improved the downloadFile function, I would like to validate the retry mechanism, so I created a unit test:

func TestDownloadFileRetry(t *testing.T) {
  log.Init()
  url := "https://example.com/nonexistentfile.jpg"
  savePath := "test_image.jpg"
  err := downloadFile(url, savePath)
  if err == nil {
    t.Error("It was expected to fail, but it succeeded, which may indicate that the test was invalid.")
  }
}

This point that I did:

Uses a URL that is guaranteed to fail (nonexistentfile.jpg)
Checks that the function returns an error after retry attempts
Confirms that the retry loop is working as expected and logging messages are written

Conclusion

This small PR made a tangible improvement in robustness of CLImanga downloads.
Although the feature is simple, it taught me important lessons about error handling, retries, and structured logging, while allowing me to apply the log system I created in the first PR.

The combination of retry logic and logging ensures users get reliable downloads and developers have clear insight into what went wrong, if anything.

A log system for the CLI tool

Sheng-Lin Yang — Fri, 21 Nov 2025 18:27:29 +0000

Repository: CLImanga
Issue: create LOG system (file based) for CLImanga
PR: feat: add log system

The first issue I chose to work on for CLImanga was surprisingly simple at first glance:
"Create a logging system for the project."

Before opening this PR, I had never built a logging system in Go.
I mainly relied on:

printf in C
console.log
console.error

And honestly, I believed those were enough for most programs.

But as I began exploring the issue, I realized a real project requires far more like:

Persistent logs
Structured messages
Error-level separation
Execution tracing
Debug-friendly information (file, line, timestamp)

This PR became my first deep dive into designing a custom, project-specific logging system.

Based on the issue and discussions with the project owner, the logging system needed to:

Write logs to a fixed file: logs/latest.log
Provide INFO and ERROR loggers
Include metadata:
- date
- time
- file name
- line number
Support helper utilities to easily log:
- the current function name
- the start/end of wrapped functions
Overwrite the log file on each program run to avoid unlimited growth

These requirements guided my design choices.

The final implementation is located in the log package and uses four Go standard libraries:
I used several libraries like: log, os, runtime, and time:

log:

Info  = log.New(logFile, "INFO: ", log.Ldate|log.Ltime|log.Lshortfile)
Error = log.New(logFile, "ERROR: ", log.Ldate|log.Ltime|log.Lshortfile)

The flags ensure each log entry includes:

date
time
short file name + line number

os:

Used to manage file and directory operations:

Create logs/ directory
Open or create latest.log
Truncate the file at every startup so the log doesn’t grow forever

os.MkdirAll("logs", 0755)
os.OpenFile("logs/latest.log", os.O_CREATE|os.O_WRONLY|os.O_TRUNC, 0644)

runtime:

This was the most interesting part.

I learned to use runtime.Caller to retrieve information about the function that called the logger helper:

pc, _, _, _ := runtime.Caller(1)
runtime.FuncForPC(pc).Name()

tip: if switch the number 1 as different number, it means how deeper layer want to know

This allowed me to:

Dynamically capture function names
Generate messages like:

INFO: Starting function main.DownloadManga

time:

Used to mark program start time in the log:

time.Now().Format(time.RFC3339)

This makes every run easy to identify when debugging.

When implementation, the following is the overall workflow of the logging system:

Initialization (Init())

When the program starts:

Ensure the log directory exists
Create or overwrite latest.log
Create two loggers: Info and Error
Write a startup banner with timestamp

func main() {
  log.Init()
  log.Info.Println("Application Started.")
  catchProgramExit()
  fmt.Println("Welcome to CLImanga!")
  ...
}

Function Wrapping (WrapFunction())

This helper automatically logs:

When a function starts
When it finishes Example:

func WrapFunction(fn func()) func() {
  return func() {
    Info.Printf("Starting function: %s", functionName)
    fn()
    Info.Printf("Finished function: %s", functionName)
  }
}

This instantly improved debugging readability.

Logging caller function name (LogFunctionName())

This helper logs whichever function invoked it like:

func readChapter(mangaName *string, selectedChapter *manga.ChapterSelect, chapterList *[]manga.ChapterSelect, appInstance fyne.App, appWindow fyne.Window) {
  log.LogFunctionName()
  ui.DisplayChapter(appWindow, 'r', *mangaName, selectedChapter, chapterList)

  appInstance.Run()
}

This was especially helpful during development, when tracing flow across multiple files.

Conclusion

Although this was a "small" feature, it became one of the most educational PRs I have worked on.

It taught me real-world logging techniques, improved my Go skills, and helped me contribute meaningful infrastructure to the CLImanga project.

This logging system will support future development and debugging — including my own future PRs.

Setting up CI and automated testing

Sheng-Lin Yang — Fri, 14 Nov 2025 22:28:38 +0000

In my repository Repo-snapshot I set Continuous Integration (CI) workflow with GitHub Actions by creating two folders: .github/, workflows/, and a file named ci.yml

## Structure

repo-snapshot/
├── .github/
│   └── workflows/
│       └── ci.yml
├── src/
│   ├── cli.ts
│   ├── file-collector.ts
│   ├── file-utils.ts
│   ├── git-info.ts
│   ├── index.ts
│   ├── output-builder.ts
│   ├── toml-config.ts
│   └── tree-structure.ts
└── tests/
    ├── file-utils.test.ts
    ├── index.test.ts
    └── output-builder.test.ts

The workflow configuration looks like this:

name: CI
on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup pnpm
        uses: pnpm/action-setup@v2
        with:
          version: 10
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: "20"
          cache: "pnpm"
      - name: Clean install
        run: pnpm install --frozen-lockfile --prefer-offline
      - name: Check formatting
        run: pnpm format:check
      - name: Lint
        run: pnpm lint
      - name: Test
        run: pnpm test

I set the CI to trigger on any Pull Request or Push to the main branch, which runs checks for the following:

pnpm setup
Node.js setup
dependencies installation
code formatting
ESLint checks
testing

Since I use pnpm to manage dependencies, it is necessary to set up pnpm first to ensure all dependencies are installed correctly. Next, I set up Node.js to make sure dependencies are installed for the correct Node version defined in package.json. Then, the workflow checks whether formatting, linting, and tests run successfully.

By automating formatting, linting, and testing in CI, I learned how much time and effort can be saved by automatically ensuring code quality on every pull request or push. This approach helps catch errors and maintain standards without manual intervention and reassures me that even if I or collaborators forget a step, CI will enforce it. After setting this up, I became confident that future projects would benefit from the same workflow—resulting in more consistent code, fewer bugs, and faster feedback. Overall, incorporating these checks into CI reinforced the importance of automation in development pipelines and convinced me this is a vital strategy for every project.

Since completing the CI workflow, I feel it greatly benefits the project. Even for different or new projects, if anyone forgets to format, lint, or properly test code, CI reminds the coder of problems in the pull request and blocks any code that could cause side effects.

After setting up the CI, I contributed to another project, Repopal, by creating unit tests.

Its testing structure differs from mine in folder naming, directory layout, and configuration files:

## Structure

repopal/
├── __tests__/
│   ├── unit/
│   │   └── file.test.ts
│   └── vitest.config.ts
└── src/
    ├── file.ts
    ├── fileMap.ts
    ├── git.ts
    ├── loadConfig.ts
    ├── main.ts
    └── output.ts

Because the project differs somewhat, I first read and understood its structure. Then I chose a relevant part to create unit tests. If the testing framework had been different from mine, I would have had to learn a new one. Fortunately, the project also uses vitest, so I was able to write tests more easily than if it had used another framework like Jest.

Unit testing for my CLI tool

Sheng-Lin Yang — Sat, 08 Nov 2025 03:22:27 +0000

In my CLI tool, Repo-snapshot which is built using TypeScript and Vite, I decided to implement unit tests to ensure my functions work correctly and handle edge cases. For testing, I chose Vitest along with @vitest/coverage-v8.

Why I Chose These Tools

Vitest: Vitest is a modern unit testing framework specifically designed for Vite projects. It integrates seamlessly with TypeScript, is fast, and supports features like mocking, snapshots, and coverage.

@vitest/coverage-v8: This plugin provides detailed code coverage reporting using V8’s built-in coverage tool. It helped me identify which parts of my code were fully tested and which were not.

I chose these tools because they fit perfectly with the TypeScript + Vite environment of my CLI tool and allowed me to write tests efficiently without extra configuration overhead.

Setting Up Vitest in My Project

Here’s how I set up Vitest and coverage in my project:

Install dependencies:

pnpm add -D vitest @vitest/coverage-v8

Configure Vitest: I created a vitest.config.ts file in my project root:

import { defineConfig } from "vitest/config";

export default defineConfig({
  test: {
    coverage: {
      enabled: true,
      provider: "v8",
      include: ["src/**/*.ts"],
      exclude: ["tests/**", "node_modules/**"],
    },
  },
});

Update TypeScript config: I modified tsconfig.json to include test files and support ES modules for tests:

{
  // Visit https://aka.ms/tsconfig to read more about this file
  "compilerOptions": {
    // File Layout
    "rootDir": "./",
    "outDir": "./dist",

    // Environment Settings
    // See also https://aka.ms/tsconfig/module
    "module": "nodenext",
    "target": "ES2020",
    // For nodejs:
    "types": ["node", "vitest", "vitest/globals"],

    // Other Outputs
    "sourceMap": true,
    "declaration": true,
    "declarationMap": true,

    // Stricter Typechecking Options
    "noUncheckedIndexedAccess": true,
    "exactOptionalPropertyTypes": true,

    // Recommended Options
    "esModuleInterop": true,
    "strict": true,
    "jsx": "react-jsx",
    "verbatimModuleSyntax": false,
    "isolatedModules": true,
    "noUncheckedSideEffectImports": true,
    "moduleDetection": "force",
    "skipLibCheck": true,
  },
  "include": ["src", "tests"],
  // Ignore tests and node_modules
  "exclude": ["node_modules", "dist"]
}

Add test scripts in package.json:

{
  "scripts": {
    "test": "vitest run",
    "test:watch": "vitest --watch",
    "coverage": "vitest run --coverage"
  }
}

After this setup, I could run all tests with:

pnpm test

Or test a specific file:

pnpm test tests/file-utils.test.ts

Writing test cases for my CLI tool was a learning experience. Some functions were straightforward, but others had tricky edge cases. For example, one function that parsed repository paths could fail if a user entered an unexpected format. I had to think carefully about input validation, which was an “aha!” moment—writing tests made me anticipate situations I hadn’t considered.

There were times I got stuck on mocking parts of the CLI output. Stepping away and revisiting the problem later helped me find simpler, cleaner solutions. This taught me that unit testing isn’t just about catching bugs—it also improves your design and code clarity.

During testing, I uncovered a few interesting scenarios:

Projects containing a TOML config file required careful handling in tests to avoid errors.
Edge cases for file paths on different operating systems required me to handle both forward slashes (/) and backward slashes (\).

These discoveries proved the value of testing even small utility functions—tests caught potential runtime errors before users did.

Before this project, I had very little hands-on experience with unit testing. Through this process, I learned:

Unit testing helps catch bugs early and improves the reliability of your code.
Even small functions deserve tests to handle unexpected input or edge cases.
Testing encourages better design and foresight in programming.

Going forward, I plan to write unit tests for almost every function or class I contribute to, as it saves time and effort in the long run and makes projects more robust.

Conclusion:

This experience with Vitest showed me that testing is not just an optional step—it is an essential part of software development. I now feel much more confident incorporating tests into my future projects, and I understand how they can prevent subtle bugs and improve overall code quality.

Experiences in Hacktoberfest 2025

Sheng-Lin Yang — Sat, 01 Nov 2025 02:53:22 +0000

From my first to my fourth issue, I used two programming languages: Python and Golang.

Starting with the first issue, which was just a try, to the last one, which was a real challenge for me. I moved from a small Python issue to a well-structured Golang project. From working on an algorithm to developing a CLI tool with LLM integration and a Python project analyzer.

I feel contributing to open-source projects is not as difficult as I once thought. There are so many projects across diverse topics that we might not even imagine, and many of them are creative and useful. Different projects require different languages and skills, offering many opportunities to contribute.

During Hacktoberfest 2025, I experienced projects that helped me get involved in different fields. I learned Golang for backend development, WebSocket, and CLI tools, mostly working on the Python project analyzer.

Therefore, I believe that if I keep this enthusiasm for open source, I can continue to learn more. Moreover, after this event, I am confident about continuing to contribute to open-source projects.

Circular dependency check in Python

Sheng-Lin Yang — Fri, 31 Oct 2025 22:54:50 +0000

I worked on my fourth issue, Add circular dependency,
and created my fourth Pull Request (PR): New feature with circular dependency in Python project

This is my last issue in Hacktoberfest.
I have challenged myself three times, and this one is the biggest one to me.

This project implements many features and functions. Until now, I had never contributed to a project that uses one language to analyze or check for bugs and issues in another—like this project, which uses Go to check Python projects, whether they are small, medium, or large.

For this feature, I implemented three options under the check command: --select deps or --select circular, --allow-circular-deps, and --max-cycles. The main objective was to detect circular dependencies between the files in a project. If any were found, the tool would display the files involved. With --max-cycles, users can specify how many circular dependencies are allowed in the entire project.

While working on this project, I spent time communicating with the project owner about the problems I encountered, hoping to get useful feedback. One tip I learned from my open-source course was to use git grep to efficiently find files containing specific keywords.

I implemented the core functionality for detecting circular dependencies, but I am still working on how to display the exact line and column numbers in the output.

Through this challenge, I learned the importance of clear communication between developers and how to use tools like git grep to search for information efficiently.

Even though this challenge is not completely finished yet, I am committed to seeing it through because it is a great opportunity to work on a well-structured, meaningful project.

Open Source Contribution: CLI Project with LLM

Sheng-Lin Yang — Fri, 31 Oct 2025 22:16:11 +0000

I worked on my third issue, No rate limiting for LLM API calls,
and created my third Pull Request (PR): Fix no rate limiting if llm api calls

After my first Go open-source project, I wanted my next contribution to involve a command-line tool (CLI). I found a CLI project that used an LLM, and I was interested because I had not realized before that a CLI tool could make use of a large language model (LLM). This sparked my curiosity, so I left a comment expressing my interest in fixing the bug.

The issue was that the CLI only implemented LLM usage but did not handle scenarios where many users might issue API requests in a very short time. This could cause crashes or provider rate-limit errors. I saw this as a great opportunity to join and solve the problem.

For this PR, I used the Go package "golang.org/x/time/rate," which provides a robust rate limiter to control how frequently certain actions can occur. It allowed me to regulate API calls and prevent exceeding the provider's rate limits by limiting the request frequency and handling bursts efficiently.

I set an API rate limit as a variable and improved a function so that when the CLI makes an API call, it obeys the set rate; if requests exceed the limit, it returns an error and an empty result. After updating the function, I wrote a unit test to make sure everything was working as expected. I was pleased to see it perform correctly.

Before opening my PR, I left a comment for the repository owner because I was not sure if the test file's location in the project structure would be acceptable, and there was no documentation about it. Once my unit test was approved, I submitted the PR and received a prompt response.

This experience made me feel ready to challenge myself with even bigger CLI projects in the future.

First Golang project I contributed

Sheng-Lin Yang — Fri, 31 Oct 2025 21:21:54 +0000

I worked on my second issue, Typing indicators for users,
and created my second Pull Request (PR): Improve UX for users

For this second PR, I worked on a WebSocket project using Go (Golang) that allows users to communicate on a web page and send private messages to each other. In this PR, I made a simple improvement by adding a feature to show when "someone is typing" on the website. Although it is a small feature, it helps enhance the user experience for everyone using the chat.

The code changes for this PR were not very extensive, but this was my first open-source project using Go (Golang), and I wanted to challenge myself and gain confidence with this new language. I made several changes across four files: home.html (HTML), styles.css (CSS), a type definition (Golang), and a function (JavaScript). When I ran the program and saw it working in the browser, I felt really proud to have contributed to an open-source project in Go.

After creating this PR, I began considering what kinds of topics or projects are especially well-suited for Go. For example, I already have ideas for CLI tools and am interested in contributing to CLI projects using Go. I am excited to keep learning and look forward to making more contributions!