DEV Community: Bregwin Jogi

The End of the Beginning: My Open Source Journey so far

Bregwin Jogi — Fri, 29 Nov 2024 22:04:06 +0000

This is the final post for the OSD assignment Release 0.4
I am hoping to graduate in a couple of weeks.

Learning about open source so far has been really rewarding, I understood the ups and downs surrounding it and even started my own open source project RefactorCode.

I wanted to work on one more issue, since I am not sure if the work I did satisfies all the requirements for the final release.

I worked on an issue in ml-mdm by Apple where some files needed to be updated with a new library used for parsing arguments.

I looked at the project and found that only a couple more files were left to be using the simple-parsing library. My contributions included:

Creating data classes based on existing arguments.
Replacing old argument parsing code with functions utilizing the new data classes.
Applying the same updates to multiple files in the repository.

I ran the files so see if there were any issues and I noticed the arguments not being passed correctly and threw an error, I realized that the README also needed a small spelling fix to pass the new arguments.

Once I updated it, the script ran properly. Later, I made a pull request documenting the changes.

The other pull requests I made for the assignment are still waiting to be reviewed, I am not sure when it would get merged. I will be addressing any suggested changes if there ends up being any.

Edit: Happy to say that 2 of the pull requests (ml-mdm & issue-metrics) got merged!

Overall, since I am also graduating soon, looking back over the past 3 years, I am happy that I was able to learn new things related to coding, I ended up doing a co-op, and now I will be on the lookout to start my career. I am not sure where I will be in a few years, but I will somehow figure it out as I go along.

Here’s to the end of one chapter and the beginning of another.

Working on New Open Source Projects - Release 0.4 - Part 2

Bregwin Jogi — Fri, 29 Nov 2024 21:31:36 +0000

Last time, I was planning on what issues I could take on for this assignment, I found a couple more and started working on them.

I looked at another issue on a tool created by GitHub to update how the "time in draft" is calculated for a pull request. When a PR changes from "ready for review" back into "draft", the time is not calculated, so there needs to some updates for it.

Fixing Brave browser bug

Regarding the working on the brave issue, because of the sheer size of the repo, it was tough to find the exact file where the filter lists and global defaults are handled, but I found in an interesting way.

I backtracked the file through VS Code search!

I figured they all must be part of the same file, so I searched for that particular text:

I saw the actual text is stored in another file to make it easier to modify, I look at the variable name corresponding to it.

I saw the file, where is getting used and saw that the components in that file are the same the one I saw in the browser.

At the top of the file, saw the functions it uses to open the tabs for the filter settings, they were creating the tabs directly, hence the cause of the bug.

I looked into how to focus on a tab if the particular URL is already open an existing tab and updated the code.

I was worried the issue was going to be a lot harder because I wasn't sure what exactly was causing the issue. But the update seems to fix it.

I made the pull request for it, but I am not sure if it will get merged anytime soon because it is a low priority issue right now.

Fixing issue-metrics bug

For this issue, I looked into where the time in draft is actually calculated and found the following section of code:

Then I found the function that calculated the draft time, right now it does a subtraction of "ready_for_review" time from "created_at" time.
I noticed that it is using the github3 library for the project and looked at how to get the draft times. While looking at how the ready for review date was calculated, I realized there isn't a direct way to get the draft, and I had to look through the events for that particular issue and get review and draft events.

Then I had to calculate the time from each review and draft interval.

I then updated the code fix the issue:

I also updated the tests and added a couple more to test the function.

Once all the tests passed and everything worked as expected, I made a pull request.

I found another good issue as well, but I will let you know about that and an overview of my everything over the past few months in another blog post!

Working on New Open Source Projects - Release 0.4 - Part 1

Bregwin Jogi — Fri, 29 Nov 2024 20:51:06 +0000

As part of my OSD course at Seneca College, I have been contributing to open source for the past few months. This is the final assignment before I graduate, so I am looking to contribute to other projects that are a little bigger in scope than last time.

There was an issue I decided not to work on the brave browser last time because it was outside the skills I currently have, so I am planning to work on another issue which I personally encountered while using the browser. When you click the filter lists or global defaults from this menu, it creates a new tab every time. This is different from when you click settings, where if there is already a settings tab open, it focuses on that tab. I am thinking of taking this issue.

The other issue I want to work on, that I haven't found out yet, but I am hoping to find one soon!

Since the semester is coming to an end, I am having a lot of assignments due in the coming weeks. So I am uncertain on what all I could contribute to within the time I have. But I have a couple of repos I am looking into for now.

How to publish your node.js package to NPM

Bregwin Jogi — Fri, 22 Nov 2024 23:05:56 +0000

I recently added my node.js console application RefactorCode to NPM to make it easier for users to install the application without cloning the repo. It was surprisingly simple and I have laid out the steps below:

You need to first create an npmjs account from here: https://www.npmjs.com/

Once that's done, go to the root directory of the project, and type:

npm login

This will take you to the login page and after being successfully authenticated, type npm publish to push the project to NPM:

And that's it!

Here is my package if you are curious:
https://www.npmjs.com/package/refactorcode

Other stuff

I made a release for the application by tagging a release:

git tag -a v1.0.1

And the pushing it to github:

git push --follow-tags

I also tested if others were able to access the application by asking my brother to try installing it, he was able to set it up from NPM pretty easily after looking at the README file.

Although, it is a bit harder compared to normal packages since you have to specify environment variables for the API key, but the screenshots helped.

Trying bigger tasks in Open Source

Bregwin Jogi — Wed, 20 Nov 2024 20:57:17 +0000

I started with trying to work on bigger tasks in open source projects, so that I can improve my skills. I started it last week, and you can see my blog for that here: [link]

This week I worked a project called react-chatbotify which is a library for a creating custom chatbots, it was a very beginner-friendly repo and there were already several tasks labelled for new contributors. I worked on an issue for adding new test cases to a component that allows the user to add custom checkboxes for their chatbot.

They were using a library called testing-framework on top of Jest which allows testing similar to how the user would interact with components (right-clicking a button). I wasn't familiar with this library at first, but I learned more about it by working on this issue. I looked at the existing test cases to see how it was implemented and starting adding test cases for the components. Once I completed most of them, I ran the test file, 4 of the tests ran, but the 5th one was throwing an issue.

After some debugging, I realized the checkboxes were not selected properly and changed the way how I selected them. This fixed the issue and all the test cases passed.

Once I did a review of the code to see everything works as expected, I made a pull request for it.

Trying to do Larger contributions to Open Source

Bregwin Jogi — Wed, 20 Nov 2024 20:22:07 +0000

This week, I worked on several open-source projects trying to work on larger issues and making better contributions. While I completed some of the issues, I realized some others were beyond my current skill level. It taught me a lot about how to gauge the scope of work and knowing what to contribute to.

One example was an issue in the Brave Browser project to add a policy for disabling a feature. The documentation provided clear instructions, so I decided to give it a try. After cloning the repositories, one for the whole project and the other containing the actual browser code which is a fork of chromium (it was HUGE). I installed the necessary tools (like depot_tools) and packages needed by Chromium. Despite realizing early on that the project was massive, I decided to give it a shot.

However, when I tried to implement the policy, I discovered I needed to trace all instances of the feature and understand where the policy flags needs to be applied. Ultimately, I lacked the experience and knowledge to proceed, so I decided not to continue. This was a good reminder that I have a long way to go, but it was also exciting because I know there are so many cool things I never worked with. The project's documentation and instructions were excellent, and I hope to revisit this task when I’m better prepared.

Next, I focused on smaller issues in other repositories:

VS Code Python Extension by Microsoft

The issue involved preventing test coverage from running a second time if it had already failed. I located the GitHub Actions workflow file and found the step responsible for running test coverage. By using the needs argument, I made the step depend on the earlier test steps to be completed. After updating the workflow and creating a pull request, I was happy to see it accepted and merged.

Detect-Secrets by Yelp

This project scans codebases for exposed secrets. There was a feature request (labelled as good first issue by the repo authors) to display the total number of secrets found after a scan. I added functionality to count and display the number of secrets in the terminal.

Restler-Fuzzer by Microsoft

The issue was to add some kind of validation to ensure that the dictionary used by a function doesn't have non string values. I wrote a validation function for it and added test cases to confirm it worked without breaking existing code.

These experiences reminded me how much I still have to learn. While I couldn’t complete everything I started, I’m grateful for the opportunities to contribute and improve my skills.

Adding Continuous Integration to my Project

Bregwin Jogi — Sat, 16 Nov 2024 00:57:22 +0000

This week, I implemented continuous integration (CI) for my GitHub project, RefactorCode. Since the code is hosted on GitHub, I decided to use GitHub Actions for this purpose. My goal was to ensure that all tests run automatically on every push to the repository. This way, I could prevent breaking changes and keep the application more stable.

Setting Up CI with GitHub Actions

I had already set up testing with Jest last week, so this week’s task was to configure GitHub Actions to run tests in each push to the repo. I used a preconfigured GitHub Actions workflow, which allowed me to run the tests as well as run ESLint.

After setting it up, I verified that tests were executed automatically on every push. This setup gives me peace of mind because I no longer have to worry about breaking existing features when making multiple changes.

Collaborating with another Student

I also worked on tests for a project by another student, Vinh, called Barrierless (great name, by the way) which translates text files into different languages. My contribution was adding tests to check whether the command-line arguments such as setting options for model type, AI provider, and output file worked as expected.

In return, Vinh added some test cases to my project as well.

Takeaways

Adding CI to RefactorCode was a much-needed improvement that improves the stability and reduces bugs in the project. Working on another person’s project was also a great experience, as it gave me more info about how their code was set up and helped me write better test cases.

Overall, this week’s updates made both projects more reliable and was a fun learning experience.

Testing Troubles with Jest & ESM and how to fix it

Bregwin Jogi — Sat, 09 Nov 2024 01:17:45 +0000

This week, I was tasked with adding tests to my RefactorCode project. As I started adding new features, I noticed that some existing features were breaking, and it became increasingly difficult to test everything manually. This made it clear that I needed to implement proper automated testing to ensure the application is stable.

Since I had prior experience with Jest from my previous Cloud Computing for Programmers course, where I worked with Node.js, I decided to use it for this project as well. I started by writing some tests to check the functionality of my code. However, I encountered a few errors that I hadn’t faced before. After some debugging and searching through Stack Overflow, I realized that there are additional configurations required when using ESM (ECMAScript Modules) with Jest. In my previous project, I had used CommonJS, which worked perfectly. While I could have opted to use Babel for the conversion, Jest offered a new beta feature that allowed ESM to run directly. I decided to give it a try, and it worked great!

This explains everything related to configuring jest with ESM: https://jestjs.io/docs/ecmascript-modules

Here is a quick overview of the setup:

Install Jest:

npm install --save-dev jest

Create a jest.config.js file. Here I set what folders to ignore as well:

export default {
  testPathIgnorePatterns: ["/node_modules/", "/examples"],
  transform: {},
};

In the package.json scripts section, use the experimental argument for jest to work with ESM modules:

"scripts": {
    "test": "node --experimental-vm-modules node_modules/jest/bin/jest.js"
}

Create a test file. I created all the tests within a test folder in root directory. Here is a simple one I created:

import { readFile, checkIfDirectory } from "../src/fileUtils";

describe("File Utility", () => {
    test("Read File", () => {
      readFile("./examples/test.txt").then((data) => {
        expect(data).toBe("Hello World");
      });

    });

    test('should return true if the path is a directory', async () => {
      const result = await checkIfDirectory('./examples');
      expect(result).toBe(true);
    });
});

If you want to test using a single test file:

npm test -- banner.test.js

For running all the tests, we use the script, we added earlier in package.json:

npm run test

Finally, the basic tests were set up. However, this was just the beginning of my troubleshooting journey. I also faced difficulties with mocking libraries and modules, especially since they were using ESM. These required extra configuration, but after some tweaking, I was able to get everything working, and the tests ran successfully.

Instead of using the regular jest.mock, you have to use jest.unstable_mockModule:

For example: await jest.unstable_mockModule("fs", () => ({
  existsSync: jest.fn(),
  readFileSync: jest.fn(),
}));

See this section for more info.

One of the core functionalities I wanted to test involved integrating with the Gemini API. Since I didn’t want to rely on the live API for testing, I decided to mock the API calls. Initially, I tried using Nock, but I ran into issues because it didn’t work well with Node’s default fetch implementation. It seemed that the Gemini library was using the default fetch instead of a third-party fetch implementation, which caused the mock to fail. After several attempts without success, I switched to another library called MSW (Mock Service Worker). Although it required a bit more setup to create a mock server, it worked flawlessly on the first try. I crafted an example response based on how the Gemini API would respond, which allowed me to test the refactored functionality.

Here is how the mock server was set up for reference:

import { http, HttpResponse } from 'msw'

export const handlers = [
    http.post('https://generativelanguage.googleapis.com/v1beta/models/gemini-1.5-flash:generateContent', () => {
        return HttpResponse.json({
                candidates: [
                    {
                        content: {
                            parts: [
                                {
                                    text: JSON.stringify({
                                        explanation: "The provided code has been refactored to address several issues and improve readability.",
                                        refactoredCode: `
                                            var count = 0;
                                            var message = "Hello";
                                        `
                                    })
                                }
                            ],
                            role: "model"
                        },
                        finishReason: "STOP",
                        index: 0
                    }
                ],
        });
    }),    
];

You can see that I am mocking a specific API endpoint that I am using for the application. Now all you have to do this add the below to start the server while testing:

import { setupServer } from "msw/node";
import { handlers } from "../mocks/handler.js";
export const server = setupServer(...handlers);

server.listen();

Reflecting on the process, this was a great learning experience for me. In hindsight, I probably should have checked the compatibility of the libraries I was using and considered any potential issues beforehand. Despite the challenges, I’m glad to have reached a point where my tests are running smoothly. I look forward to adding more tests in the future and improving the overall stability of my project.

A brief recap of what I did this Month

Bregwin Jogi — Thu, 31 Oct 2024 23:56:37 +0000

Happy Halloween and Diwali!

Now that today's the last day of October, I wanted to make a quick recap on my involvement with the Open Source Community, what I learned so far, and things I found interesting.

I became familiar with open source projects contributing to 6 projects, ranging from fixing very small typos to adding new features. Here are the projects and the pull requests I made for them:

Nats.io - Fixing a small spelling mistake.
https://github.com/nats-io/nats.docs/pull/752
TLDR - Adding Documentation to Azure Cli
https://github.com/tldr-pages/tldr/pull/13934
ScottPlot - Adding a minor center property
https://github.com/ScottPlot/ScottPlot/pull/4335
VS Code Python - Removing JSDocs types
https://github.com/microsoft/vscode-python/pull/24300
Mozdownload - Adding dependabot configuration to update GitHub actions.
https://github.com/mozilla/mozdownload/pull/703
Magika - Adding a function to validate python README markdown
https://github.com/google/magika/pull/739

You would notice that a lot of the pull requests are very small fixes. The main reason for that to be honest because I wasn't fully skilled to fix some of the issues I thought to contribute to. When I looked at some issues and the associated codebase, I realized it might be better to work on a simpler issue than stopping an issue halfway through because of the lack of knowledge. However, these simpler issues taught me a lot about how to interact with contributors, creating pull requests and following the contributing guidelines for these projects.

This was very helpful for some later contributions where I could focus more on coding the feature instead of worrying about other factors.

I also did some work on my own open source project - RefactorCode.
I refactored the code (touche), adding tools like Prettier and ESLint to make the code easy to maintain and added a contributing.md to make it easier in case anyone wanted to contribute to the project.

I have been doing these contributions as part of my OSD course at Seneca as a final semester student, but I am hoping that I find time to contribute to these projects even after I graduate.

Because a lot of what I like in coding was made possible through these projects, and it is fun to work with the people responsible for it.

It was a pretty busy and intense month due to having to manage other courses and midterms, but I feel it was worth it.

How to use Eslint and Prettier together for your Node.js Project

Bregwin Jogi — Wed, 30 Oct 2024 16:53:51 +0000

I recently added two major static analysis tools to my project RefactorCode : Prettier and ESLint.

It allows contributors working on the project to maintain the quality of the code by fixing formatting issues and common code errors. This means that I can simply run a command to check if the code is consistent, without looking at each file to see if it fits the guidelines.

Here's how I did it:

I installed Prettier and Eslint through npm:

npm install --save-dev prettier eslint eslint-config-prettier

We are also installing eslint-config-prettier for them to work together and not interfere with each other.

Add prettier config and ignore files (Check prettier docs for more info):

node --eval "fs.writeFileSync('.prettierrc','{}\n')"

node --eval "fs.writeFileSync('.prettierignore','# Ignore artifacts:\nbuild\ncoverage\n')"

...And you are pretty much done for Prettier, you can call format the files using the following command:

npx prettier . --write

You can also add a script to run it which I will get into later.

Now let's continue with ESLint

Run the setup for ESLint:

npx eslint --init

Complete the setup based on your requirements, here's how I did it for my project:

I added the files and folders to not be linted:

I then added scripts in package.json to make it easier to run them:

"scripts": {
    "format": "prettier --write \"**/*.{js,ts,html,css,md,json}\"",
    "lint": "eslint . ",
    "lint:fix": "eslint . --fix "
  },

When I ran Prettier for the first time, there were a lot of white spaces issues that were fixed, I checked if the program still worked properly and committed the changes. I did the same for ESLint. There were some import errors, so I fixed them manually.

After checking to see if the program still ran properly, I committed all the changes and merged it to the main branch.

There is also a way to integrate these tools with VS Code, you can install their extensions from the VS Code Marketplace:

Prettier - Code formatter

ESLint

Create a .vscode/settings.json file within the root directory of your project if you want to specify the extension settings only for your current project.

Here is the configuration I used for it to format and lint on save:

// .vscode/settings.json
{
    // Enable format on save
    "editor.formatOnSave": true,

    // Set Prettier as the default formatter
    "[javascript]": {
      "editor.defaultFormatter": "esbenp.prettier-vscode"
    },
    "[typescript]": {
      "editor.defaultFormatter": "esbenp.prettier-vscode"
    },

    // Enable ESLint to auto-fix issues on save
    "editor.codeActionsOnSave": {
      "source.fixAll.eslint": true,
      "source.organizeImports": true
    }
  }

Overall, I think tools are great. It fixed a lot of formatting errors and issues that I otherwise wouldn't have noticed. I am going to use them when starting a new project from now on.

From Regex to Ruff: Lessons Learned in Contributing to Magika

Bregwin Jogi — Tue, 29 Oct 2024 23:43:18 +0000

This is another contribution I did as part of my OSD600 course at Seneca College. This would be one of my final ones, as other assignments catching up to me. But I really liked that I was able to contribute to many interesting projects as part of this assignment.

This time, I contributed to Magika, a tool by Google to detect file content types using machine learning. It seemed like a pretty cool project and I thought I might be able to use it for my open source project RefactorCode which surprise-surprise refactors your code.

The issue was to update the github actions workflow to check that their README (for the python package) doesn't contain relative paths. I first reached out to the issue author with a couple of questions, and he quickly clarified them.

So I forked the repository, created a new branch, and opened a draft pull request. I added a new function that parses the markdown for links. I used regex for this. There is also regex validation to check if the links are relative. It then uses the requests module to check if the links are valid or not. If a link is invalid, it is added to an error list so the program finds all errors in one run instead of stopping at the first one. It then prints out information about each error.

The goal was to prevent the package from building if the documentation contains links that users can't access. It took me a bit of time to get the regex working, but with some help from Stack Overflow, I figured it out.

Once I was ready, I converted the draft to an actual pull request and waited for feedback from the issue author. I received some great constructive feedback early on. The code did not pass the ruff format check, so I had to update the code to the correct format. There was also a suggestion to make the function more generic to Markdown. So I updated the code for it. I also made it work for folders but based on the suggestions from the author that it made it overcomplicated, I reverted it for only one markdown file path.

I tested it in a modified README to see if it worked, and it worked great!

After a series of feedbacks and updates, the code met all requirements and was successfully merged into the main branch. There was a lot more communication and feedback compared to my previous contribution, and I learned a lot about how to communicate asynchronously.

Overall this whole series of contributions was a really fun,
It made me better to understand code bases with different styles and format, how to contribute to open source effectively. I gained a huge amount of appreciation for the countless contributors across various repos who have spent their time and effort, sharing code freely for everyone.

I look forward to being a part of this community in the future and continuing to give back.

Contributing to Open Source Projects #3

Bregwin Jogi — Wed, 16 Oct 2024 21:58:44 +0000

This week, I worked on updating the GitHub Actions workflow for the Mozdownload repository, a download tool created by Mozilla for Firefox and Thunderbird. The GitHub issue I decided to work on was to adjust the Dependabot configuration to automate Python dependency updates related to Node.js actions.

The issue was well-documented, so I had a clear idea of where to make the changes. The goal was to ensure that Dependabot would automatically update these dependencies instead of manually making the updates.

What I did:

Checked the current setup:

I looked at the existing dependabot.yml file to understand how it was configured.
I also reviewed GitHub’s documentation to confirm the correct approach.

Made the required changes:

I updated the configuration to run weekly checks for dependency updates.

Opened a pull request:

After making the changes, I submitted a pull request explaining what I did.

Surprisingly, I received quick feedback on the pull request. The issue author responded promptly, suggesting a minor modification, which they implemented themselves. Shortly after, the pull request was successfully merged into the repository.

Looking forward to contributing to another project next week!