Step 3 - final result

Step 1 - planning
Step 2 - progress
Step 3 - release

Technical feature of the work

Issue 1

• added an edge case to the existing if/else statement to fix the CI failure issue.

The problem occurred as previous solution does not catch the edge case when certain variables are passed. Because of missing the edge case, else block is executed returning false, which caused CI to fail.

In the new solution, new edge case was added to continue the current if code flow when certain variables are passed. This edge case will be executed when array of excludedVariables includes a variable. If it does, it will delete it.

...
let excludedVariables = ["fips", "sep"];
...

else if (excludedVariables.includes(variable)) {
          delete editedHousehold[entityPlural][entity][variable];
}
...

Result

You can find more details in here: PR

Issue 2

• prettier . --write was added to the existing lint script to be able to handle both linting and formatting without the need for an additional Prettier command.

Before

"lint": "eslint --ext js,jsx . && prettier -c ."

After

"lint": "eslint --ext js,jsx . && prettier . --write"

Result

You can find more details in here: PR

Issue 3

• make format rule was changed to not use Black. Instead of using Black, npm run lint was used to lint the project as below.

install:
    npm ci
build:
    npm run build
debug-no-lint:
    ESLINT_NO_DEV_ERRORS=true npm start
debug:
    npm start
test:
    npm run test
deploy-setup:
    cp gcp/.gcloudignore ./.gcloudignore
    cp gcp/app.yaml ./app.yaml
    cp gcp/main.py ./main.py
    cp gcp/social_card_tags.py ./social_card_tags.py
    cp gcp/requirements.txt ./requirements.txt
    cp -r social_cards/ build/static/media/social_cards
deploy: build deploy-setup
    gcloud config set app/cloud_build_timeout 1000
    y | gcloud app deploy --project policyengine-app
    rm app.yaml
    rm .gcloudignore
    rm main.py
    rm requirements.txt
lint:
    npm run lint

You can find more details in here: PR

Issue 4

• "sort-keys-fix/sort-keys-fix" rule was added to eslintrc.yml file as below for ascending sorting.

      "rules": {
          ...
          "sort-keys-fix/sort-keys-fix":
            ["error", "asc", { "caseSensitive": false }],
        },

• fix command was added to scripts in package.json file to be able to fix the lint problem with single command, npm run fix.

  "scripts": {
    "fix": "eslint src --fix --ext .ts,.tsx,.js",
    ...
  },

• This changes applies to all of the keys in Object, not limited to React component property only.

Result
Examples of unsorted prop

Unsorted props will give you an error.

With the help of command, npm run fix, it will automatically sort everything as expected.

Fix result (props are ordered alphabetically now!)

After the fix, there is no error.

You can find more details in here: PR

What did you learn from this process?

Makefile
'Make' is used to compile the program automatically. To be able to use 'make', it needs 'Makefile' to define multiple tasks/commands to be executed. 'Make' is commonly used in many open source projects for final compilation, and it can be installed using make install command. When cleaning is needed for this process, use make clean command.

There are lots of tasks you can add on top of the current 'Makefile'. For example, you can add a task to back up the project or initialize the project as below.

# Backup the project
backup:
    cp -r project backup

# Initialize the project
init:
    npm init

How well did you do achieving your goals?

As indicated in Step 1 - planning, I had two main goals for the release 0.4: to learn new skills and push myself out of my comfort zone. This project was the largest one I have contributed to so far. Numerous people were involved in each issue or pull request (PR). The projects I had contributed to before were comparatively smaller, so I would usually receive comments on the PR I submitted right away in a fast-paced environment. However, this time was different. Whenever I pushed a PR, it took days and days to be reviewed. For instance, one reviewer pinged another person to join the open discussion on the PR. I would describe it as a slow-paced environment. Nevertheless, I learned a lot through this experience.

I typically look at specific pieces of code, fix the issue, and move on. But it was not that simple in a larger project like this. Reviewers reminded me that the bigger picture cannot be ignored simultaneously. Additionally, I learned a new method to automate processes using make during this project. I can confidently say that I achieved both goals I set during the planning step.

Reasoning
Some of PRs are not merged yet. For examples, I am still waiting for teams to review the PR I pushed 2 weeks ago. For another PR, there has been a conversation between maintainers what to do next with this pr, but no progress so far.

In addition, there was a comment about properly separating content within PRs. For example, I created several PRs, some of which had a nested structure. In one case, the second PR I made included the content of both the PR 1 and the PR 2. The third PR was even more complex, encompassing the contents of PR 1, PR 2, and PR 3. I believe that all these unorganized PRs makes it challenging for maintainers to review them efficiently. Going forward, I think I need to separate each PR I create in the same repository for better readability and overall efficiency.