DEV Community: Mayank Kumar

Releasing dev-mate-cli on npm

Mayank Kumar — Sat, 23 Nov 2024 00:52:32 +0000

This week, I successfully released my CLI tool, dev-mate-cli, to the public npm registry. It was a rewarding experience that involved learning and refining my project. Here’s a detailed account of how I did it, along with lessons I learned and tips for anyone looking to release their own package.

dev-mate-cli - npm

command line tool using LLMs for code documentation. Latest version: 1.0.3, last published: 3 hours ago. Start using dev-mate-cli in your project by running `npm i dev-mate-cli`. There are no other projects in the npm registry using dev-mate-cli.

npmjs.com

Choosing a Release Tool and Registry

As my project was written in TypeScript and designed as a Node.js CLI tool, I chose npm for hosting my package. It’s the most popular package registry for JavaScript developers, and I was already familiar with using it to install dependencies. Publishing to npm made sense, as it would make my tool accessible to a broad audience.

You can create an account at npmjs.com. Once your account is ready, publishing a package involves using simple and well-documented commands.

Process for Releasing

Preparing the Project for Release
- I added a bin field in my package.json file to make my CLI executable. This field maps the CLI command (dev-mate-cli) to the script that should run when the command is invoked.
- Ensured all needed dependencies, like dotenv, were correctly listed in the dependencies field of package.json rather than devDependencies. This is critical because devDependencies are not installed when users download the package.
Testing Locally with npm link
- Before publishing, I ran npm link to simulate how users would install and use the package globally. This helped me test the CLI commands and catch any errors.
Building the Project
- Since the project was written in TypeScript, I ensured my build script compiled the source code correctly. Running npm run build generated the necessary JavaScript files in a dist folder.
Publishing the Package
- After verifying everything worked locally, I logged into npm using npm login and published the package.
- The --access public flag was required since I wanted my package to be publicly available.
```
   npm publish --access public
```

User Testing

For the testing phase, I asked a fellow developer to try out dev-mate-cli. The tool worked as intended, and she found it easy to use with the provided instructions. Her main suggestion was improving the README to make the setup process clearer. Specifically, she recommended placing critical setup steps (like environment variable configuration) at the top of the documentation, which I promptly implemented.

Lessons Learned

Managing Dependencies: One of the key issues I encountered was the dotenv module being listed as a devDependency. Since npm doesn’t include devDependencies in the published package, this caused a runtime error. This was a valuable reminder to double-check the dependencies section before publishing.
Streamlining Documentation: User testing with a developer revealed areas for improvement in my README. For instance, moving instructions for setting up environment variables (API_KEY and BASE_URL) to the installation section made it easier for users to get started.

Overall, publishing dev-mate-cli was a rewarding process, filled with valuable lessons. I hope this blog helps other developers navigate the npm publishing process more easily. If you’re building your own CLI tool, feel free to reach out with questions or suggestions!

Introducing CI Pipeline for Clang-Format Checks in faker-cxx

Mayank Kumar — Thu, 21 Nov 2024 11:56:15 +0000

For the second part of my Release 0.3 contribution to the faker-cxx project, I addressed an issue involving the addition of a Continuous Integration (CI) pipeline. The goal was to ensure that any new code pushed to the repository adheres to the clang-format configuration provided in the root folder. This was an exciting opportunity to deepen my understanding of CI/CD workflows, especially since I am actively learning about them.

The Issue

The faker-cxx repository already had a clang-format configuration file, but there was no automated process to check if submitted code adhered to it. Previously, contributors had to run clang-format locally before committing, which some contributors skipped and was also prone to human error. Automating this check would ensure consistency and reduce the chances of merging pull requests with formatting-related problems.

My Approach

To begin, I familiarized myself with clang-format and its configuration guidelines. I had previously used clang-format for contributions to this repository, but this time, I needed a more in-depth understanding to integrate it into a CI pipeline. Here’s the official release document I referred to.

Then, I explored the GitHub Actions Marketplace for pre-configured clang-format actions, hoping to find a verified and actively maintained option. Unfortunately, none met these criteria, so I decided to write the workflow from scratch.

Creating the GitHub Actions workflow involved defining steps to:

Check out the repository.
Install clang-format if it wasn’t already available.
Cache dependencies to speed up the CI pipeline.
Run clang-format on relevant files.
Check for unformatted files and fail the CI run if any were found.

Implementing the CI Workflow

Here is the core of the GitHub Actions workflow I wrote:

jobs:
  check_formatting:
    name: Check Code Formatting
    runs-on: ubuntu-24.04

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Cache clang-format dependencies
        uses: actions/cache@v3
        with:
          path: /tmp/apt-cache
          key: clang-format-${{ runner.os }}-${{ hashFiles('**/apt-packages.txt') }}
          restore-keys: |
            clang-format-${{ runner.os }}-

      - name: Install clang-format
        run: |
          if [ ! -f /tmp/apt-cache/clang-format-18 ]; then
            sudo apt-get update
            sudo apt-get install -y clang-format-18
            touch /tmp/apt-cache/clang-format-18
          fi

      - name: Run clang-format
        run: |
          clang-format src/**/*.cpp src/**/*.h include/**/*.h -i -style=file

      - name: Check for unformatted files
        run: |
          git diff --exit-code || (echo "Code is not formatted correctly" && exit 1)

Key Features:

Path Filters: I ensured the workflow only ran when changes were made to files relevant to the clang-format check. This optimization avoided unnecessary CI runs for unrelated updates like documentation changes.
Caching: By caching the clang-format dependencies, I reduced the time taken for subsequent runs. This step was implemented using the actions/cache@v3 action.

Testing and Deployment

After writing the workflow, I tested it on my fork of the repository before pushing it upstream. This step was helpful to catch any issues early. Once I confirmed it was working as expected, I opened a pull request to the main repository.

ci: add clang-format #987

mayank-Pareek posted on Nov 20, 2024

This closes #953

This PR introduces a GitHub Action to check code formatting using clang-format.

Workflow

Runs only on push and pull_request events for include/**/*.h,src/**/*.cpp and src/**/*.h files.
Cache check for clang-format-18 to avoid re-installation if it is already installed.
Validates formatting using git diff and fails the workflow if unformatted files are detected.

View on GitHub

The maintainer reviewed and merged the PR after a quick review, as the CI pipeline functioned smoothly and added significant value to the repository.

Reflection

Adding this CI workflow to faker-cxx helped streamline the development process by automating an otherwise manual task. The repository now has an extra layer of validation, ensuring that all incoming code adheres to the defined coding standards. This experience enhanced my knowledge of setting up CI pipelines, including caching and optimization techniques.

Increasing Code Coverage in faker-cxx

Mayank Kumar — Thu, 21 Nov 2024 11:20:49 +0000

For the Release 0.3 milestone of my OSD600 course, I returned to contribute to the faker-cxx library, a C++ library designed for generating realistic fake data. As someone who had previously contributed to this project, I was eager to take on a more challenging issue. This time, I focused on increasing code coverage for a specific module.

The Issue

The function ISBN10 generates a 10-digit ISBN, sometimes with the letter "X" as the last character (representing a check digit of 10). The challenge is in the fact that this occurrence is random and relatively rare.

std::string ISBN10()
{
    const auto isbn10 = string::numeric(9, true);
    int sum = 0, weight = 10;
    for (size_t i = 0; i < 9; i++)
    {
        sum += (isbn10[i] - '0') * weight;
        weight--;
    }
    int checkDigit = sum % 11;
    if (checkDigit != 0)
    {
        checkDigit = 11 - checkDigit;
    }
    if (checkDigit == 10)
    {
        return isbn10 + "X";
    }
    return isbn10 + std::to_string(checkDigit);
}

While the function works well, the existing test covered it minimally, running it once to check the result. The random nature meant edge case of generating an ISBN ending in "X" was often missed.

My Approach

Before diving into the code, I spent time understanding how ISBN generation and validation worked. The check digit calculation involves a weighted sum of the first nine digits, which must be divisible by 11. If the remainder is 10, the check digit becomes "X". This process provided the basis for writing effective tests.

The original test checked for validity but did not focus on the edge case of "X". I modified it to ensure it only handled ISBNs without "X". To address the edge case, I introduced a new test. Given the randomness, generating "X" reliably required multiple iterations which I achieved by adding a loop to maximize the chance of generating "X". As a fallback, if "X" was not generated, I used a pre-defined valid ISBN ending with "X".

feat: improve codecov for commerce module #986

mayank-Pareek posted on Nov 20, 2024

This closes #907

This PR improves the test coverage for the ISBN10 function in commerce.cpp and the associated commerce_test.cpp file.

Changes:

Updated shouldGenerateIsbn10 : Updated to check only ISBNs without X.

Added shouldGenerateIsbn10WithX : Specifically tests for the check digit - X.

  std::string generatedIsbn10;
  bool foundXCase = false;
 
  for (size_t i = 0; i < 100 && !foundXCase; i++)
  {
      generatedIsbn10 = ISBN10();
      if (generatedIsbn10[9] == 'X')
      {
          foundXCase = true;
      }
  }
 
  if (!foundXCase)
  {
      generatedIsbn10 = "094339600X";
  }

Improved Test Coverage

commerce.cpp from 98% to 100%.
commerce_test.cpp from 96% to 99%.

Note: While the tests achieve 99% coverage for commerce_test.cpp, the if (!foundXCase) branch in shouldGenerateIsbn10WithX is intentionally left uncovered to maintain logical clarity and introduce fallback.

View on GitHub

Challenges and Learnings

Reviewing coverage reports with gcov and lcov was instrumental in identifying the uncovered cases.
Writing tests for functions with randomness requires strategic thinking.
Breaking tests into specific cases (e.g., with and without "X") helps ensure coverage while maintaining readability.

After my changes, the tests covered all possible outputs of the ISBN10 function, increasing overall module coverage. Although one fallback line remained technically uncovered, thorough testing and the inherent randomness of the function were finely balanced.

Setting up Continuous Integration (CI) for dev-mate-cli

Mayank Kumar — Thu, 14 Nov 2024 04:39:44 +0000

In this blog, I will walk through my experience setting up a CI workflow for my project dev-mate-cli, including insights into collaborating on testing and CI with a peer's project. Along the way, I took on the optional challenge of integrating a linter and explored how this addition improves code quality and the CI experience. Here’s how it all came together:

Setting Up the GitHub Actions CI Workflow

To start, I set up a simple CI workflow using GitHub Actions, designed to run tests whenever I pushed new changes. I’ve worked with basic CI setups like this before so I knew what to do. I created a YAML file in the .github/workflows directory, with the following configuration:

name: CI
jobs:
  unit-test:
    name: Unit Tests
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: 'lts/*'
          cache: 'npm'
      - name: Install Dependencies and Run Tests
        run: npm install-ci-test

This workflow checks out the repository, sets up Node.js, installs dependencies, and runs the tests. As soon as I pushed the changes, GitHub Actions triggered the workflow, running all my Jest test suites, which passed successfully. This was a great way to ensure that each update to my project wouldn’t inadvertently break any functionality. Checkout the action run here.

Collaboration for Testing

As part of the lab in my OSD600 course, I also needed to collaborate with a peer, Anh Chien Vu. We agreed to add tests to each other's projects. Since we had already worked together, we knew each other’s code style and project setups, which made this collaboration easier. Anh Chien’s PR included an additional test suite, which improved my test coverage. His code was well-structured, so after testing his changes locally, I was comfortable merging the PR.

Writing tests for Anh’s project, VShell, involved testing core CLI functions to verify program details and AI response generation. View the PR below:

Add tests for server.js #21

mayank-Pareek posted on Nov 12, 2024

Description

This PR aims to add a new file with unit tests for server.js

Changes Made

Added server.test.js containing the following unit tests for server.js -

should set up CLI information i.e. name, version and description.
should use default values when no config file exists.
should exit when no files(for processing) are provided with debug enabled.
should process files and call promptAI

These tests have 100% code coverage for server.js file.

Testing Details

[x] Unit tests added
[x] Unit tests passed

Checklist

[x] Code compiles correctly
[x] Tests have been written and run
[x] Code adheres to the style guidelines
[x] Ready for review

View on GitHub

Since both of our projects used Jest, I had a smooth start, but I ran into some challenges mocking modules due to dependencies. I had to use jest.resetModules() to clear the module cache after each test and directly import the required modules, which was a new but valuable lesson. This hands-on collaboration allowed me to experiment with test structures I can now apply in my own project.

Adding a Linter to the CI Workflow

To further enhance my CI pipeline, I took on the optional challenge of integrating a linter. The project initially used ESLint for linting, but I ran into multiple configuration complexities due to dependencies and plugins for Jest, Prettier, and TypeScript. To simplify things, I migrated to Biome, which combines both formatting and linting, reducing the need for multiple tools.

After updating the project to use Biome, I created a lint job in the CI configuration to automatically check for linting errors. Here’s what the addition looked like:

lint:
  name: Biome Lint
  runs-on: ubuntu-latest
  steps:
    - name: Checkout
      uses: actions/checkout@v4
    - name: Setup node
      uses: actions/setup-node@v4
      with:
        node-version: 'lts/*'
        cache: 'npm'
    - name: Install Dependencies
      run: npm ci
    - name: Run Biome Lint
      run: npm run lint

Adding a linter to the CI helped enforce consistent coding practices, catching potential errors before merging.

Conclusion

Overall, I learned that even a basic CI setup can provide a strong foundation to the project. It helps by giving immediate feedback on the code's stability and catching issues before merging. Having CI with both tests and lint checks makes code review easier and encourages better code quality, and I plan to implement it in all future work.

Cover Image by freepik

Adding Jest to dev-mate-cli

Mayank Kumar — Sat, 09 Nov 2024 03:39:24 +0000

This week, I focused on improving dev-mate-cli by adding robust testing with Jest, a popular JavaScript testing framework. The goal was to enhance reliability and encourage contributions by ensuring new changes align with the project’s standards. Here’s a breakdown of the tools I used, the setup process, lessons learned, and how testing improved the code.

mayank-Pareek / dev-mate-cli

A command line tool to quickly document your code

dev-mate-cli

A command-line tool that leverages OpenAI's Chat Completion API to document code with the assistance of AI models.

Watch this Demo video to view features.

Features

Source Code Documentation: Automatically generate comments and documentation for your source code.
Multiple File Processing: Handle one or multiple files in a single command.
Model Selection: Choose which AI model to use with the --model flag.
Custom Output: Output the results to a file with the --output flag, or display them in the console.
Stream Output: Stream the LLM response to command line with --stream flag.

Usage

Basic Usage

To run the tool, specify one or more source files or folders as input:

npm start ./examples/file.js

For processing multiple files:

npm start ./examples/file.js ./examples/file.cpp

For processing folders:

npm start ./examples

Command-line Options

Note: Use npm start -- -option to pass the option flag to the program, as npm…

View on GitHub

Why Jest?

I chose Jest for its popularity, TypeScript compatibility, powerful mocking capabilities, and large community. Jest is widely adopted in the JavaScript/TypeScript ecosystem and provides built-in support for many essential features like snapshot testing, coverage reports, and a simple setup. Since I already had some experience with Jest in JavaScript, I was excited to deepen my understanding by integrating it with my project that uses TypeScript and ESLint.

Setting Up Jest with TypeScript and ESLint

Configuring Jest to work smoothly with TypeScript and ESLint was more complex than I anticipated. I first installed Jest as a dev dependency and added three most-relevant scripts:

  "test": "jest -c jest.config.js --runInBand --",
  "test:watch": "jest -c jest.config.js --runInBand --watch --",
  "coverage": "jest -c jest.config.js --runInBand --coverage"

For the initial test case, I picked a utility function, checkIterable, that checks if an AI response can be streamed. Writing tests for it revealed a bug: it didn’t handle null inputs properly, returning null instead of false. I corrected this by ensuring it returns a Boolean consistently. This first success confirmed that tests could effectively catch errors in code logic, saving time later in the development process.

Mocking AI Responses with Jest

The biggest challenge was simulating AI responses from OpenAI's API. Initially, I tried using nock to intercept HTTP requests, but while researching I found that OpenAI had mocking capabilities for its constructor , which let me use captured JSON responses to simulate interactions with the model.

I structured the main ai.test.ts to cover three essential cases: Basic AI Response, API Errors and Missing Environment Variables. With the jest.spyOn function, I could capture console logs and errors, confirming that messages were displayed as expected for both successful and failed API calls. This approach allowed me to identify gaps in error handling.

Lessons Learned

While I had limited experience with testing, setting up Jest for TypeScript and experimenting with AI response mocking deepened my understanding of automated testing. This process was a great reminder of how thorough testing improves code quality and promotes a smoother contribution experience. Going forward, I’m committed to making testing a core part of my development workflow and look forward to expanding the test suite as dev-mate-cli evolves.

Enhancing Contributions for dev-mate-cli

Mayank Kumar — Sat, 02 Nov 2024 04:04:39 +0000

This week, I focused on improving and encouraging contributions to my project, dev-mate-cli. As open-source projects thrive on community involvement, I recognized the need to create a seamless experience for new contributors. Here’s how I worked towards that goal.

Introducing CONTRIBUTIONS.md

First of all, I created a new file called CONTRIBUTIONS.md. This document outlines the guidelines and setup necessary for development. Some of these instructions were previously present in README.md, but to separate documentations for contributors, I added them in the new file along with some new guidelines. Having clear instructions will help potential contributors understand how they can effectively engage with the project, fostering a more collaborative environment.

Aligning Contributions with Prettier and ESLint

Next, I turned my attention to ensuring that all contributions are aligned with our coding standards. I realized that while I had previously added Prettier for code formatting, it wasn’t functioning as intended. So, I enhanced the configuration to ensure that code would be automatically formatted upon saving, along with introducing scripts to run prettier in command-line.

After setting up Prettier, I followed the similar process and integrated ESLint into the project. ESLint helps catch errors and enforce coding conventions, making it easier for contributors to maintain code quality. By providing clear linting rules, I aimed to reduce potential friction points during the contribution process.

VSCode Settings for a Smooth Development Experience

To further facilitate contributions, I added a .vscode which includes essential configurations to ensure that contributors using Visual Studio Code have a consistent experience. I also included extension recommendations to help streamline the development process.

All of the changes discussed above were squashed into a single commit, you can view all the changes here..

Conclusion

I believe these enhancements will attract more contributions while keeping disruptions to a minimum. By providing clear guidelines and automated tools for formatting and linting, I hope to create a welcoming environment for developers who want to contribute to dev-mate-cli. As the project evolves, I look forward to seeing how these changes positively impact the project growth.

My Hacktoberfest 2024 Experience

Mayank Kumar — Fri, 01 Nov 2024 02:49:48 +0000

This October, I dove into Hacktoberfest 2024, excited to contribute to open-source projects and gain real-world coding experience. As a relatively new participant in open source, I didn’t know what to expect - only that I wanted to explore and learn as much as possible. This journey introduced me to a diverse range of projects and coding practices, which expanded my perspective on software development.

Hacktoberfest itself was an adventure. Initially, finding issues that were manageable, open to new contributors, and within my skill set took time. The Hacktoberfest tag was both a blessing and a challenge: while it directed me toward projects welcoming contributions, it also attracted thousands of developers with the same goal because of growing popularity. I discovered that many repositories with these tags were either overloaded with PRs or had issues that were not truly beginner-friendly(at least in my-terms). Still, with persistence, I found several exciting projects that offered a chance to make a meaningful impact.

Tackling Four Unique Pull Requests

Throughout Hacktoberfest, I explored and worked on many different projects, each with its own ecosystem and contribution challenges. Below is a rundown of the four PRs entailed and what I gained from them -

TLDR Pages (Adding a Page) - My journey began with a fairly straightforward PR - adding a new page to TLDR Pages, a collaborative project for simplified, community-driven command documentation. Working on this was a smooth entry point, letting me focus on writing concise, readable documentation while following the project’s strict contribution standards. It was not overly technical, but it deepened my understanding of guideline’s importance in open-source contributions and helped me become familiar with the PR process on GitHub.
Deno Project (Primordials Replacement) - Next, I contributed to the Deno repository which is a JavaScript runtime focused on security and modern practices, and my issue dealt with its Node.js compatibility layer. My task was to replace some global functions with “primordials” to prevent potential prototype pollution. This PR had me researching the project’s coding standards, understanding JavaScript runtime internals, and navigating a large codebase written in a combination of JavaScript, TypeScript and Rust. Setting up the environment was challenging and required understanding Deno's unique structure. This PR pushed my comfort zone and I got insight into how JavaScript runtimes are built.
Faker C++ (Adding Locale to a Module) - The third project, Faker C++, was inspired by the popular Faker.js library, which generates realistic mock data for testing. My task was to add locale support to a module, which allowed me to work on a C++ codebase - something I had not done in a while. Setting up the environment in C++ was a different kind of challenge, involving tools like Blaze, CMake, Ninja, and clang-format.
Valid-GTIN (Optimizing GitHub Actions Workflow) - My fourth and final PR involved CI/CD with GitHub Actions, a domain I’ve been eager to contribute in. The issue here was to update the workflow file to optimize when tests should run, based on changes to specific files. This required me to research GitHub Actions’ path filtering and to figure out the best way to apply it without disrupting the main workflow. It was a lightweight project, but it gave me a chance to work with CI/CD and understand the considerations that go into managing resources in active projects.

The Challenges and Joys of Open Source

While I ultimately completed four PRs, the journey involved exploring nearly a dozen other issues that I couldn’t resolve for various reasons. Some were overly complex, and others introduced dependencies or setup requirements that I couldn’t resolve within my timeframe. Each issue presented unique challenges: some were in languages or frameworks I hadn’t worked with, while others required new configurations I’d never set up before. I deliberately avoided asking to be assigned issues immediately, instead working through them locally to avoid blocking others until I was confident I could handle them.

This approach was sometimes frustrating but taught me a lot. I learned to persevere through setups, to read documentation thoroughly, and to test things locally until I felt prepared to push changes. By the end of Hacktoberfest, I have probably reviewed over a hundred repositories, many of which are incredibly interesting even if they didn’t have open issues suitable for me. These explorations have expanded my understanding of various programming languages and domains, and I now have a list of projects I plan to revisit and contribute to in the future.

Lessons Learned and Future Plans

Reflecting on Hacktoberfest, I’m grateful for the growth I’ve experienced both technically and personally. Here are a few lessons I’m taking with me:

The Value of Good Documentation: Projects with well-documented contribution guidelines and helpful communities stood out. Clear documentation not only makes contributions smoother but encourages newcomers to participate.
Perseverance Pays Off: Finding the right issues and setting up environments was often time-consuming. But sticking with it led to valuable learning experiences and the satisfaction of seeing a PR merged.
Expanding My Toolset: I gained exposure to C++ setups, JavaScript runtimes, CI/CD workflows, and more. Hacktoberfest pushed me out of my comfort zone to use new tools and frameworks.
The Open-Source Community is Inspiring: Being a part of the open-source community and contributing to shared projects was deeply fulfilling. Knowing that my code might help someone else or improve a project definitely felt nice.

Although Hacktoberfest is over, my open-source journey is only beginning. I plan to keep contributing to projects I found interesting and giving back to a community that has given so much to developers.

Adding Workflow Filters to Valid-GTIN

Mayank Kumar — Fri, 01 Nov 2024 01:51:57 +0000

For my fourth Hacktoberfest PR, I was determined to work on something related to CI/CD, Docker, or perhaps something DevOps-oriented. After hunting through several repositories, I found some promising CI/CD issues, but they often required touching multiple workflows or were deeply embedded in existing configurations. Given the potential risk of disrupting the projects with complex changes, I decided to keep looking until I found a better fit. That’s when I came across valid-gtin - a lightweight JavaScript library designed to validate GTINs (Global Trade Item Numbers).

0xflotus / valid-gtin

A lightweight validator function for GTINs

valid-gtin

A zero cost lightweight validator function in native javascript for GTINs

Usage

const validate = require("valid-gtin")

if (validate(GTIN)) {
  console.log(":)")
}

CLI

valid_gtin <gtin>

Development

To run the tests please checkout this repository and run:

npm run test

Stargazers over time

View on GitHub

At first glance, it was a straightforward repository with only a few files and a single function responsible for GTIN validation. But that’s what made it perfect: it was clean, lightweight, and, best of all, the issue at hand was exactly what I was looking for.

The Issue

The issue was focused on improving the test.yml GitHub Actions workflow file by adding path filtering to make testing more efficient by only running tests on specific file changes and thus reducing unnecessary runs. Earlier, every commit to the main branch or new pull requests, triggered tests, regardless of whether relevant files had changed. My goal was to update the workflow so that tests would only run when certain files (like .js, .ts, or GitHub workflow files) were modified. This was an ideal opportunity to learn about workflow filtering while keeping things relatively low-risk.

Tests should only run if some special files were edited #109

0xflotus posted on Oct 21, 2024

To reduce the costs, the tests should only run, if one of the following files was touched:

*.{mjs,js,ts}
.github/workflows/*.yml
package.json
tsconfig.json

View on GitHub

Making Changes

After forking the repository and cloning it locally, I created a new feature branch and started by researching GitHub Actions path filtering options. I had never actually set up path-specific filters in a workflow before, so I spent some time experimenting with different configurations to get a better understanding of how to target files accurately and found relevant documentation on GitHub Docs.

In the test.yml file, I updated the workflow to be more efficient by modifying the on event so it would listen only to changes in specific file types, hence making the CI/CD process lighter and more efficient. The updated workflow configuration included path filters which looked like this:

on:
  push:
    branches:
      - main
    paths:
      - '*.mjs'
      - '*.js'
      - '*.ts'
      - '.github/workflows/*.yml'
      - 'package.json'
      - 'tsconfig.json'

Creating the Pull Request

After configuring the workflow, I committed my changes, pushed the branch, and opened a pull request. Setting up CI/CD filters sounds straightforward, but it was surprisingly fun digging into the specifics and understanding how path filters could optimize workflows. I liked the idea of improving the efficiency of a smaller project, where every little optimization could streamline contributions and keep the repository agile. The repository owner reviewed the pull request fairly quickly and the PR was successfully merged.

Optimize Test Workflow to Run Only on Relevant File Changes #113

mayank-Pareek posted on Oct 31, 2024

Fixes #109

This PR modifies the GitHub Actions workflow to trigger tests only when specific files are changed, reducing unnecessary test runs and saving CI resources. With this update, the tests will only run if any of the following files or patterns are modified:

Files with extensions .mjs, .js, .ts
.github/workflows/*.yml
package.json
tsconfig.json

Changes Made:

Updated .github/workflow/test.yml by adding paths filtering under push and pull_request triggers, specifying the relevant files to watch.

 paths:
   - '*.mjs'
   - '*.js'
   - '*.ts'
   - '.github/workflows/*.yml'
   - 'package.json'
   - 'tsconfig.json'

View on GitHub

Reflection

This PR marked a significant step for me in Hacktoberfest, allowing me to contribute to CI/CD workflows, which I’ve been interested in for a while. Working on a smaller repository was also refreshing, as it gave me space to try new configurations without the pressure of handling a huge codebase. I enjoyed this contribution for the balance it struck between learning something new and enhancing the project in a meaningful way.

My Third Hacktoberfest PR: Adding Locale Support to Faker C++

Mayank Kumar — Thu, 31 Oct 2024 23:25:00 +0000

For my third Hacktoberfest contribution, I worked on a fascinating project called Faker C++. This C++ library, inspired by the well-known Faker.js, is designed to give developers a flexible tool for generating realistic fake data. This repository had several open issue to choose from, I picked one of the issue to familiarize myself with C++ development again.

Issue Overview

The issue I tackled was to add locale support to a specific module within the project. This enhancement was intended to allow the plant module to generate data in different languages, making the library even more adaptable for developers around the world. This change would provides developers with the option to create location-specific data, which is especially valuable for testing localized applications or creating demos tailored to different regions.

add locale to plant module #898

cieslarmichal posted on Sep 07, 2024

ref book module

View on GitHub

Approach and Setup

Setting up my environment took more time than anticipated. Since I hadn’t worked with C++ in a long-time, I decided to use Visual Studio for the setup that I had used in past rather than my usually IDE - Visual Studio Code. I forked the repo, cloned it locally, created a new branch and followed the contribution guidelines to download and setup the tools necessary for development. I attempted to use Bazel as the build management tool, but after a few complications, I switched to CMake with Ninja, which proved to be a more compatible setup for this project. Additionally, I had to configure clang-format to ensure my code followed the project’s specific formatting standards. To make all of these processes less-complicated and run some bash scripts, I also installed WSL on my Windows 11 operating system to use Linux-kernel. This setup phase was challenging but necessary to maintain consistency with the codebase.

Changes Made

Once the environment was ready, I focused on understanding the module’s structure and the intended changes. Familiarizing myself with the codebase was an essential step since I was working in a relatively unfamiliar environment. Fortunately, the codebase was well-documented, and the repository owner provided reference to a previous pull request that addressed similar functionality in a different module. This example provided helpful context and clarified how I should approach the code changes.

The primary code updates involved adding enUS as a default locale for the plant module, which required adding a new struct that accepted a locale parameter. This change enabled the module to generate locale-specific plant data based on user preference. I also updated the existing plant_test file to incorporate locale testing, ensuring that the new feature worked as expected and was thoroughly covered by the test cases. Testing was another area where I needed to catch up on C++, and working through this allowed me to get more comfortable with C++ testing frameworks in this case GoogleTest, which turned out to be a nice learning experience.

feat: add locale to plant module #970

mayank-Pareek posted on Oct 28, 2024

This PR introduces locale support in the plant module, with enUS set as the default.

Fixes Issue: #898

Changes:

Locale Parameter for Plant Definitions
- Added getPlantDefinition() with locale as parameter to support locale-based plant data.
- Defaulted to enUS as a fallback for undefined or unsupported locales:
```
const struct PlantDefinition& getPlantDefinition(Locale locale) {
   switch (locale) {
    default:
        return enUSPlantDefinition;
    }
}
```
Locale-Specific Naming in Plant Data
- Updated array naming for plant data, to reflect the locale:
```
const auto enUSTrees = std::to_array<std::string_view> {/* data */};
```
Test Suite Updates
- Updated plant_test to incorporate the new locale parameter.

[x] Ran all unit tests after building project to ensure no breakage from the locale addition.

View on GitHub

After finalizing the code changes, I ran clang-format and executed all the tests to ensure the modifications met the repository’s standards. The repository owner reviewed my pull request and suggested a small adjustment to include Doxygen tags for the new locale parameter to maintain thorough documentation. I quickly incorporated these changes, ensuring that the locale parameter was fully documented. After this revision and passing all checks, my pull request was successfully merged, marking the completion of my third Hacktoberfest contribution.

Conclusion

Reflecting on this pull request, I found the experience both challenging and rewarding. Setting up a C++ development environment took longer than expected, but this step helped me understand the importance of having a robust setup, especially when working on a project in an unfamiliar language. Working with testing frameworks in C++ was also a nice experience, giving me insight into how modular code can be thoroughly tested in a language like C++. In the end, this contribution not only added locale flexibility to Faker C++ but also expanded my comfort zone, helping me gain new skills that I can bring to future C++ projects.

My Contribution to Deno 2.0

Mayank Kumar — Tue, 29 Oct 2024 03:44:23 +0000

Over the past couple of weeks, I came across multiple blogs and YouTube videos about the v2.0 release of Deno - a JavaScript, TypeScript, and WebAssembly runtime built with Rust and designed to offer secure defaults for developers. Since I was searching for an issue to create my second PR in Hacktoberfest, I decided contributed to this trending repository. My pull request focused on the compatibility layer of Deno, which was enhanced with the recent release to better support Node.js and npm. The specific task in my PR involved replacing built-in global proxy functions with primordials in the Node compatibility layer.

denoland / deno

A modern runtime for JavaScript and TypeScript.

Deno

Deno (/ˈdiːnoʊ/, pronounced dee-no) is a JavaScript, TypeScript, and WebAssembly runtime with secure defaults and a great developer experience. It's built on V8 Rust, and Tokio.

Learn more about the Deno runtime in the documentation.

Installation

Install the Deno runtime on your system using one of the commands below. Note that there are a number of ways to install Deno - a comprehensive list of installation options can be found here.

Shell (Mac, Linux):

curl -fsSL https://deno.land/install.sh | sh

PowerShell (Windows):

irm https://deno.land/install.ps1 | iex

Homebrew (Mac):

brew install deno

Chocolatey (Windows):

choco install deno

WinGet (Windows):

winget install --id=DenoLand.Deno

Build and install from source

Complete instructions for building Deno from source can be found in the manual here.

Your first Deno program

Deno can be used for many different applications, but is…

View on GitHub

Exploring the Project

Given that Deno is a large and complex project with multiple languages and layers of functionality, setting up the environment was a critical first step. The setup process required installing Rust and configuring Cargo, along with other necessary dependencies for local development. Following the contribution guidelines, I reviewed both the project documentation and setup instructions. This part took some time but was essential for navigating the project’s structure and development process smoothly.

Working on the Issue

The issue I tackled was part of a larger effort to increase code reliability and security in Deno’s Node compatibility layer - Issue #24236. As per the documentation, Primordials are frozen intrinsic objects in Deno, used to safeguard against prototype pollution by replacing direct references to global objects with safe alternatives. In my case, I worked on updating randomInt.ts - a file responsible for the randomInt function’s implementation in the core.

My task was to replace certain global methods, like Number.isSafeInteger, with their primordial equivalents e.g., NumberIsSafeInteger. To ensure accuracy, I first researched the correct primordials for each global method. This led me to explore both the Node and Deno documentation to confirm the use of primordials and understand their role in reducing security risks in Deno’s core.

Code Changes and Pull Request

As always I created a new branch for this pull request and made the necessary changes to the randomInt.ts file, while reviewing similar accepted pull requests to align with best practices. I followed Deno’s style guidelines for linting and formatting, but I was not able to run the lint script due to some issue with cargo. I decided to push the code changes after testing locally and to review the linting errors(if any) generated by the CI workflow on GitHub. I submitted my PR, following the guidelines for new pull requests and eventually got a lint error. After changing the PR to draft and resolving the error locally, I pushed the new changes which passed all the tests and it was ready for review.

fix(ext/node): use primordials in ext\node\polyfills\internal\crypto\_randomInt.ts #26534

mayank-Pareek posted on Oct 25, 2024

Towards #24236

used primordials from ext:core to replace usage of built-in functions

View on GitHub

While waiting for review on my PR I noticed new commits were merged into main and my branch was out of sync. Out of boredom, I decided to merge the new main branch into my branch which interestingly made my PR fail most of the cases. After investigating the cause for a while I concluded it was because of the new changes still under CI/CD workflows runs. Since I had the previous branch locally I forced pushed to origin in order to revert the merge and decided to leave merging for reviewers. The PR was reviewed and accepted after several hours and this time it did not fail any tests during merge.

Conclusion

This PR allowed me to explore Rust alongside JavaScript in a large, open-source project being used by numerous users. Though it involved minimal code changes, contributing to a project as substantial as Deno was a valuable experience, helping me understand how small adjustments can enhance overall system stability and security.

My First Hacktoberfest Pull Request

Mayank Kumar — Wed, 23 Oct 2024 17:15:20 +0000

Finding the Right Repository

The first couple of weeks of Hacktoberfest were challenging as I spent a significant amount of time searching for the right repository to contribute to. The competition for beginner-friendly issues was fierce, and many repositories existed solely to allow people to make low-effort pull requests (PRs), which wasn’t the kind of contribution I wanted to make. Eventually, I found a suitable repo: tldr by tldr-pages.

tldr-pages / tldr

📚 Collaborative cheatsheets for console commands

What is tldr-pages?

The tldr-pages project is a collection of community-maintained help pages for command-line tools, that aims to be a simpler, more approachable complement to traditional man pages.

Maybe you're new to the command-line world? Perhaps you're just a little rusty or can't always recall the arguments for commands like lsof, or tar?

It certainly doesn't help that, in the past, the first option explained in man tar was:

$ man tar
...
-b blocksize
   Specify the block size, in 512-byte records, for tape drive I/O.
   As a rule, this argument is only needed when reading from or writing to tape drives,
   and usually not even then as the default block size of 20 records (10240 bytes) is very common.
...

There seems to be room for simpler help pages, focused on practical examples. How about:

This repository is just that: an ever-growing collection of examples…

View on GitHub

The tldr-pages project is a community-maintained collection of simplified help pages for command-line tools. It serves as a more approachable alternative to traditional man pages, making it easier for users to find and understand examples for common commands. Given its active maintenance and practical relevance, it seemed like a great project to contribute to.

The Issue: Adding `npm-doctor` Command

The tldr repository had an open issue to document various npm commands, and I decided to contribute by working on the npm doctor command. This command checks the health of the npm environment, which is particularly useful for developers troubleshooting their setup.

Let's document: npm #14000

bharateshwq posted on Oct 05, 2024

Command description

This is widely used in development and most of its options are misused or never really used this would be a great contendor

Documentation

https://docs.npmjs.com/cli/commands

Platform

Linux

VCS repository link (e.g. GitHub, GitLab)

https://github.com/npm/cli

Additional information

https://docs.npmjs.com/cli/xxx https://docs.npmjs.com/cli/v10/commands

Commands

[x] npm 0a4c0f0a3705dae2a8c6d4f9f93d14f57ac6ba7b
[ ] npm access
[ ] npm adduser
[ ] npm audit
[ ] npm bugs
[ ] npm cache
[ ] npm ci
[ ] npm completion
[ ] npm config
[ ] npm dedupe
[ ] npm deprecate
[ ] npm diff
[ ] npm dist-tag
[ ] npm docs
[x] npm doctor #14262
[ ] npm edit
[ ] npm exec
[ ] npm explain
[ ] npm explore
[ ] npm find-dupes
[x] npm fund #8495
[ ] npm help
[ ] npm help-search
[ ] npm hook
[ ] npm init
[ ] npm install
[ ] npm install-ci-test
[ ] npm install-test
[ ] npm link
[ ] npm login
[ ] npm logout
[ ] npm ls
[ ] npm org
[x] npm outdated #14088
[ ] npm owner
[ ] npm pack
[ ] npm ping
[ ] npm pkg
[ ] npm prefix
[ ] npm profile
[ ] npm prune
[ ] npm publish
[x] npm query #8445
[ ] npm rebuild
[ ] npm repo
[x] npm restart #14035
[ ] npm root
[x] npm run #14035 (alias of npm run-script)
[x] npm run-script #14050
[ ] npm sbom
[x] npm search #14302
[ ] npm shrinkwrap
[ ] npm star
[ ] npm stars
[x] npm start #14035
[x] npm stop #14035
[ ] npm team
[x] npm test #14035
[x] npm token #14250
[x] npm uninstall #14201
[x] npm unpublish #14187
[ ] npm unstar
[x] npm update #14242
[ ] npm version
[x] npm view #14269
[ ] npm whoami
[ ] npx

View on GitHub

First, I installed the tldr package on my local machine to get a feel for how it works and to understand the format of the pages. The short explanation and examples it provided were clear and helpful, which encouraged me to contribute to the project.

Preparing the Fix

Before jumping into the code, I followed the recommended steps for contributing to the repository. I checked the contribution guidelines and reviewed previous pull requests to understand how to format my submission according to the project's standards.

Next, I visited the official npm documentation to learn about the npm doctor command in detail. After gathering enough information, I forked and cloned the repository locally, then navigated to the common folder; created a new branch for the change, where I added a new markdown file named npm-doctor.md as per the naming convention for sub-commands.

Here’s what I added to the file:

# npm doctor

> Check the health of the npm environment.
> More information: <https://docs.npmjs.com/cli/commands/npm-doctor>.

- Run all default health checks for npm:
`npm doctor`

- Check the connection to the npm registry:
`npm doctor connection`

- Check the versions of Node.js and npm in use:
`npm doctor versions`

- Check for permissions issues with npm directories and cache:
`npm doctor permissions`

- Validate the cached package files and checksums:
`npm doctor cache`

I made sure the examples were simple, concise, and followed the format used in other tldr-pages. After testing and running required checks on the file locally to ensure everything worked as expected, I was ready to create my PR.

Creating the Pull Request

When creating my PR, I followed the template provided by the repository, which ensured I covered all necessary details. The maintainers were quick to review my submission and requested a few small changes. After addressing their feedback, the PR was merged successfully.

npm-doctor: add page #14262

mayank-Pareek posted on Oct 18, 2024

[x] The page(s) are in the correct platform directories: common, linux, osx, windows, sunos, android, etc.
[x] The page(s) have at most 8 examples.
[x] The page description(s) have links to documentation or a homepage.
[x] The page(s) follow the content guidelines.
[x] The page(s) follow the style guide.
[x] The PR title conforms to the recommended templates.
Version of the command being documented (if known):

View on GitHub

Challenges & Learning

While this PR was relatively straightforward, mostly consisting of markdown edits, it was a great introduction to contributing to large open-source projects. The main challenge I faced was familiarizing myself with the contribution process of the project. Reading through the repository's contribution guidelines and studying previous PRs helped me understand how to format my submission correctly.

I learned that it’s essential to have a good high-level understanding of the project before starting work and reading other PRs is a good way to learn the methods of contribution. I believe that while my PR was small, it was a good starting point and it gave me insight into how to contribute to large open source projects.

Now that I’ve successfully completed my first PR, I plan to gradually increase the complexity of my contributions. My next goal is to find a slightly more challenging issue, possibly involving code or a bug fix. I’ll continue to document my progress in future blog posts.

Learning Git Rebase

Mayank Kumar — Fri, 11 Oct 2024 22:46:01 +0000

This week, I worked on refactoring my project, dev-mate-cli. As with any refactor, my primary goal was to improve the codebase by making it cleaner and more modular. However, the process didn’t stop there - I also took this opportunity to practice using Git’s interactive rebase feature to tidy up my commit history.

mayank-Pareek / dev-mate-cli

A command line tool to quickly document your code

dev-mate-cli

A command-line tool that leverages OpenAI's Chat Completion API to document code with the assistance of AI models.

Watch this Demo video to view features.

Features

Source Code Documentation: Automatically generate comments and documentation for your source code.
Multiple File Processing: Handle one or multiple files in a single command.
Model Selection: Choose which AI model to use with the --model flag.
Custom Output: Output the results to a file with the --output flag, or display them in the console.
Stream Output: Stream the LLM response to command line with --stream flag.

Installation

Clone the repository:

git clone https://github.com/mayank-Pareek/dev-mate-cli.git
cd dev-mate-cli

Install dependencies:
```
npm install
```
Set up environment variables:

Create a .env file in the project’s root directory by making a copy of .env.example file:
```
cp .env.example .env
```
Replace API_KEY and BASE_URL values with an API Key and URL generated from a Open AI's…

View on GitHub

Refactoring Goals

Before diving into Git, I wanted to focus on improving several aspects of my code:

Modularity: Breaking down large functions into smaller, reusable components.
Error Handling: Improving how the application handled different input paths.
AI Response: Refactoring how the program interacted with OpenAI's API, ensuring better separation of concerns.
Performance: Making the file handling code more efficient by introducing recursion for processing directories.

Step-by-Step Refactor

Here’s a breakdown of the steps that I took to refactor dev-mate-cli:

Move File Processing to fileHandler
My first task was to clean up the code responsible for file processing. Previously, this logic was mixed with the part of the code that handled the setup of cli program in program.ts. To improve modularity, I moved the file processing into a dedicated fileHandler module. This separated the concerns, making the code easier to maintain and test.
Make File Path Processing Recursive
Since I was already working on the file processing, I saw an opportunity to add more robustness. The function initially handled file paths but didn’t traverse directories deeply. I enhanced it by adding recursive logic to handle directories, ensuring the program processes every file within subdirectories as well.
Split AI Response Logic into Separate Functions
One function was doing too much—handling the AI request and response in one go. To simplify this, I broke it down into two functions: one for generating the response and another for handling what happens afterward. This separation of concerns not only made the code cleaner but also easier to extend in the future.
Fix Token Usage Output When Streaming Response
While streaming AI responses to the command line, I discovered that the token usage report wasn’t working as expected. This was due to incorrect handling of response chunks when streaming. I fixed the logic so that token usage would now be correctly displayed, even when data is streamed to the command line.
Add Interface and Fallback for Program Options
To ensure that the program handled missing options gracefully, I added fallback values for the model and temperature. I also created an interface to define the options type, improving type safety and making the code more predictable.

Git Rebase: Interactive Squashing

Once all the changes were made, I turned my attention to the commit history. I had made 5 separate commits, each representing a logical change. To keep the Git history clean, I decided to squash these commits into one using Git’s interactive rebase feature.

Ran git rebase main -i to start an interactive rebase with main branch.
Squashed the 5 commits into one.
Amended the commit message to summarize all the changes in a clear and concise manner using git commit --amend command.
Merged the topic branch into main branch using fast-forward merge.
Pushed the new commit to origin using git push origin main.

The interactive rebase was smooth, and I found it to be an invaluable tool for maintaining a clean project history. I also learned how important it is to commit often but keep the history readable for maintainers and collaborators.

The final commit can be checked here - https://github.com/mayank-Pareek/dev-mate-cli/commit/16fe682e17cd0983d793298adfee504b16d71537