DEV Community: Neil An

Release 0.4 - Results

Neil An — Sun, 11 Dec 2022 12:19:26 +0000

Hi everyone,

This week I completed the issues as described in my previous posts here and here.

To recap the issues:

generate a favicon.ico for our apps
This issue looks to update the favicon logo to match the current logo that they are using. My PR.
chore: create script for updating RELEASE.md before PR
This issue looks to update any RELEASE.md files when a developer changes a package. The script will ask the developer what is the scope of the PR they are making and what changes they made to a package and write to the appropriate RELEASE.md file. My PR.

Last week I completed the first issue and this week I completed the second issue. I think I paced myself well enough considering all the other work I had to do (and that it's finals week). I really liked the fact that I worked on this repo for a while now (since Hacktoberfest) and that I got to meet some really cool and helpful people from the repo.

The second issue I worked on was a little more open ended. To start, I created a script that asked the contributor what package they changed, what type of PR they were making (patch, minor, or major), and the description of changes they made. This information would then be used to update the corresponding RELEASE.md file for that package with the correct incremented version. I submitted a PR and received some feedback regarding the code. Also, I was asked to remove the versioning because of PR's may not be the same as releases. After updating my code, my PR was good to go.

Release 0.4 - My Progress So Far

Neil An — Sun, 04 Dec 2022 11:19:43 +0000

Hi everyone,

This week I worked on the issues I described here last week.

First, I tackled the issue here. This issue looks to update the favicon logo to match the current logo that they are using. To do this, I used the .svg logo they had and generated a favicon.ico with it. I created a pull request and had some feedback about it. I had only tested it visually using light mode and had not considered how it would look using dark mode. On dark mode, the icon had bad contrast since the it was dark blue on a dark grey background. So to fix this, I added a circular white background to the logo so that it would look good on both light and dark mode.

The next issue is still a WIP. I have created a basic implementation of the script, but I am still working out some logic.

Overall, I feel that I am on track to complete the issues I have chosen (hopefully).

Release 0.4 Planning

Neil An — Thu, 01 Dec 2022 02:12:09 +0000

Hi everyone,

This week I have chosen to work on the Astro Reactive Library repo for release 0.4. I chose this repo because I have been contributing to it for the last couple of months and I am familiar with the project. I will be working on two issues:

generate a favicon.ico for our apps
This issue looks to update the favicon logo to match the current logo that they are using.
chore: create script for updating RELEASE.md before PR
This issue looks to update any RELEASE.md files when a developer changes a package. The script will ask the developer what is the scope of the PR they are making and what changes they made to a package and write to the appropriate RELEASE.md file.

The first issue seems straightforward to me, but the second issue I chose is a little more open-ended. I plan to first create a basic implementation and iteratively add more features to the script to make it more comprehensive and convenient for the developers.

Releasing my SSG with NPM

Neil An — Mon, 21 Nov 2022 23:21:25 +0000

Hi everyone,

This week I released my static site generator to the npm registry.

The process for releasing my package was simple. First, you need to sign up on the npm website. Next, you need to make sure you have a package.json file in the root directory of your project. Then, created a README.md file to document how to use your package. Finally, issue the npm publish command to publish your package to the npm registry.

I didn't have to change much in my code to accommodate the release at first. But when I asked my friend to test it out for me, he found a couple things that I needed to change. First, the npm link command that I had wrote in the README file did not work. This was because the command looks for a package.json file in the current directory, but since he installed using npm, there was no package.json file in his current directory. Therefore I had to make a change from npm link to npm link nan1-ssg. The second thing he found was minor, but he saw that when he printed the version number using nan1-ssg -v, it was 0.2, not 1.01. `This was an easy fix and I updated the version number.

To try out my SSG, follow the instructions here. The README file should provide the documentation you need to use my project.

An internal PR

Neil An — Sun, 20 Nov 2022 22:00:05 +0000

Hi everyone,

This week I fixed a UI error on Telescope, an aggregate of blogs from Seneca students. The project set-up took some time for me because there were a lot of different things I had to install and use, but the documentation provided helped me set the project up. After running the project, I discovered that the sign-up form had a UI error on the YouTube/Twitch form:

The button says VALIDATE BLOG, when you're supposed to be validating your YouTube/Twitch URLs. To fix this, I first had to learn the project's code and directory structure. Eventually I found the place where the code for that form was. After making the change to VALIDATE CHANNEL(S), I received some feedback to add some padding to the button and change the text to just VALIDATE. Here's the end result:

The biggest challenge I faced was not the code itself, but using Git. I was asked to squash all my commits into 1, but I accidentally updated the branch and merged the master branch into my local branch, so I couldn't rebase properly. After some extremely helpful advice from some peers, I was able to squash all commits into one and get my PR merged.

Reviewing code for peers

Neil An — Sun, 20 Nov 2022 05:22:06 +0000

Hi everyone,

This week I reviewed some code for some fellow peers in my course.

The first review was for a PR that wanted to clarify the difference between a blog URL (HTML) and a blog feed URL (XML) during the sign-up process. I thought that it would've been a good idea to include an example of a blog URL vs a blog feed URL just for extra clarification.

The second review was for a PR that fixed a link when clicking the "About" icon in the sidebar. The PR looked good after review, but the author was having similar trouble with rebasing like I did in my PR. So, I provided him the same instructions that someone else gave me.

Adding CI to my SSG

Neil An — Thu, 17 Nov 2022 01:17:46 +0000

Hi everyone,

This week I added CI to my SSG. I used GitHub's CI service GitHub Actions to accomplish this. It was very easy to set up as I just had to find the Node.js workflow and add it.

This is what the YAML file looks like:

# This workflow will do a clean installation of node dependencies, cache/restore them, build the source code and run tests across different versions of node
# For more information see: https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-nodejs

name: Node.js CI

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  build:

    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [14.x, 16.x, 18.x]
        # See supported Node.js release schedule at https://nodejs.org/en/about/releases/

    steps:
    - uses: actions/checkout@v3
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v3
      with:
        node-version: ${{ matrix.node-version }}
        cache: 'npm'
    - run: npm ci
    - run: npm run build --if-present
    - run: npm test

Here's the link to my successful workflow run.

I also added a test to a partner's SSG. Writing a test for their SSG was not difficult as their code was easy to understand. They were using the same testing framework/workflow as me.

I think CI is extremely easy to set up and very useful to have. It's important for the main branch of a project to be running and working at all times.

Making another PR to a repo

Neil An — Mon, 14 Nov 2022 17:10:05 +0000

Hi everyone,

This week I worked on Astro reactive library, a repo that I previously worked on for Hacktoberfest. Astro reactive library uses the Astro framework to let you build reactive user interfaces.

The issue was to add a setValue method to the FormGroup class. This would allow anyone using Astro to set the values of any form controls in that form group. For example:

should produce the following result:

Since I was familiar with this repo, I didn't have to learn the documentation. The first thing I did was find the file where I had to make my changes. After finding the file, I needed to figure out how I would implement the method. I looked in the form-control to see what properties each form control has and how I could use those properties in my implementation. I found that each form control has a name and value property that I could use. So, after figuring this out, I created my first implementation for the method. I also updated a demo page I created during Hacktoberfest to use the new method and submitted a PR.

The repo owner reviewed my PR and requested I make some changes, specifically to an ESLint error and to change my method implementation to be more efficient. After making the changes, they approved my PR and merged.

Adding tests to my SSG

Neil An — Fri, 11 Nov 2022 02:24:17 +0000

Hi everyone,

This week I added some testing tools to my SSG. The project now uses Jest for testing. I chose to use Jest because it is a very popular testing framework for JavaScript. I contemplated using Mocha, but after doing some research, decided Jest was easier to use out of the box. Installing Jest was easy. All I had to do was install it using npm: npm install --save-dev jest.

Writing the test cases on the other hand was more difficult. A lot of my tests didn't work as expected and I spent a lot of time figuring out how to use different types of matchers. I also had to change some of my existing code to handle some cases correctly. For example, if a function that handled text files was given a markdown file, then that function should throw an error or reject.

I learned a lot about testing. Even though I struggled a lot with writing tests, I can see the benefits of using tests, especially when you're working in a shared repository and you have to ensure that the code works.

Adding static analysis to my SSG

Neil An — Tue, 01 Nov 2022 00:48:15 +0000

Hi everyone,

This week I added some static analysis tools to my SSG. The tools I added are Prettier and ESLint. Prettier is a code formatter to make code consistent and ESLint checks your code for any common errors/warnings.

It was easy to set both tools up. Since I was using nodejs, all I had to do was install the tools using npm. For Prettier, I used:
npm install --save-dev --save-exact prettier
and for ESLint I used:
npm init @eslint/config

Prettier changed a lot of stuff in my code. I usually put curly braces after a function or control statement like this:

if (...)
{

}

but Prettier changed to format to this:

if (...) {

}

Prettier also changed my indentation spacing and made everything look more compact.

For ESLint, it found a bunch of errors/warnings in my code. For example, a common warning was that I had unused variables in my code. There was also a warning telling me not to use async in a promise object.

To get the tools to run in the command line, I edited the package.json file and added some scripts to run Prettier and ESLint. Here is what I added:

    "lint": "npx eslint src",
    "prettier": "npx prettier --write .",
    "prettier-check": "npx prettier --check ."

To integrate these tools into my IDE (VSCode), I just added the Prettier and ESLint extensions. For people contributing to my project, I added a .vscode/extensions.json file so that these extensions would be recommended to them on opening the project.

Overall, I learned a lot about formatters and linters and why they are important when working in a shared repo.

Hacktoberfest Recap

Neil An — Sun, 30 Oct 2022 01:23:25 +0000

Hi everyone,

I have finally completed my Hacktoberfest journey. It was definitely a lot more stressful than I thought, but I'm glad I was able to complete it on time. The main problem that I had was finding the right issue to work on. It took me way too long to find the right issues that I wanted to work on.

Here are my blogs that document my journey:

I learned a few things on my journey. First, finding the right issue is important. I had to make sure the repo I was working on was documented well and had been updated recently. I also learned to start early, because I ran into a lot of problems that made me unable to continue to work and I had to scrap some issues I worked on. Most repo owners were very helpful and friendly, but I did run into some who did not answer my questions or were not responding at all. I became very familiar with contributing to a repo and I learned how to read documentation better. Finally, I learned to believe in my own skills as a programmer.

My fourth Hacktoberfest PR

Neil An — Sat, 29 Oct 2022 23:54:41 +0000

Hi everyone,

This week I completed my final Hacktoberfest PR. For my final PR, I chose to contribute to Astro reactive library. Astro reactive library uses the Astro framework to let you build reactive user interfaces.

The issue was to create a demo page showcasing everything the library has to offer with form control. This issue was interesting and a bit challenging to work on because I had to learn the Astro documentation before I could start writing code. The syntax and coding style in Astro is different from other frameworks, but it was fun learning new things. The main benefit of Astro vs other frameworks is that websites are built faster. The cool thing about Astro is that Astro is built from components and it's syntax is a superset of HTML. An Astro component is denoted by its file extension .astro.

After familiarizing myself with Astro, I started to create my demo page. I decided to use the tailwindcss framework to help me style my page since Astro supported it. This meant I had to read the tailwind documentation to style my page. Finally, after familiarizing myself with tailwind, I created the html for my page. For the demo page, I designed and created a job application page. This page included many form control types like text, radio, dropdowns, checkboxes, file upload, and a submit button. To do this, I used the built-in FormGroup from the library. I had to read the other parts of the source code to make sure I was using it correctly. Finally, I finished the page and created a pull request. The most difficult thing about this PR was reading the documentation and making sure I was using the frameworks correctly.