Step 3 - final result
Published: 2023-12-02 00:17:57

Step 1 - [planning](https://dev.to/avelynhc/step-1-let-me-plan-first-3fp0)
Step 2 - [progress](https://dev.to/avelynhc/step-2-progress-report-4ja4)
Step 3 - [release]()

-------------------------------------------------------------
**Technical feature of the work**

[Issue 1](https://github.com/PolicyEngine/policyengine-app/issues/852)

- 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.

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

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

_**Result**_
![result](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/pn5ai175xnqknjah4xi4.png)

You can find more details in here: [PR](https://github.com/PolicyEngine/policyengine-app/pull/863)

[Issue 2](https://github.com/PolicyEngine/policyengine-app/issues/865)

- `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_**
```shell
"lint": "eslint --ext js,jsx . && prettier -c ."
```

**_After_**
```shell
"lint": "eslint --ext js,jsx . && prettier . --write"
```

**_Result_**
![result](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/qd5tz2twwv6sjms48zjj.png)

You can find more details in here: [PR](https://github.com/PolicyEngine/policyengine-app/pull/871)

[Issue 3](https://github.com/PolicyEngine/policyengine-app/issues/874)

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

```shell
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](https://github.com/PolicyEngine/policyengine-app/pull/902)

[Issue 4](https://github.com/atb-brown/austin/issues/39)

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

```shell
      "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`.
```shell
  "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 
<img width="484" alt="Screenshot 2023-12-01 at 6 51 06 PM" src="https://github.com/atb-brown/austin/assets/75185537/5ff839ab-7f72-41e9-8964-8156e3cdba1f">

Unsorted props will give you an error. 
<img width="760" alt="Screenshot 2023-12-01 at 6 51 12 PM" src="https://github.com/atb-brown/austin/assets/75185537/e43fefb6-7319-4f30-80e5-1d145e50175d">

With the help of command, `npm run fix`, it will automatically sort everything as expected.
<img width="439" alt="Screenshot 2023-12-01 at 7 18 49 PM" src="https://github.com/atb-brown/austin/assets/75185537/6ff10370-e3f8-496c-b3b5-b1ebb8508d91">

Fix result (props are ordered alphabetically now!)
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/62rdngyo4y6b5tkwt44y.png)

After the fix, there is no error. 
<img width="432" alt="Screenshot 2023-12-01 at 7 19 06 PM" src="https://github.com/atb-brown/austin/assets/75185537/7d837d3e-ec2b-4c82-ae74-08ec0c42906b">

You can find more details in here: [PR](https://github.com/atb-brown/austin/pull/55)

**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. 

```shell
# 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](https://github.com/PolicyEngine/policyengine-app/pull/863) I pushed 2 weeks ago. For another [PR](https://github.com/PolicyEngine/policyengine-app/pull/871), 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.