DEV - Implement Prettier code formatting standard

[DrAcula27]

Dependency

• We don't want any devs to pick this up until after we have launched. Completing this ticket will require all devs to pause work on tickets until they have adopted Prettier. Dev lead expects to manage bugs that come up while devs are integrating Prettier

Overview

Propose formatting standard for the 311 Data repo with Prettier

More Info (optional)

Consider finding an existing open source project with well-documented code formatting rules that would work well with our codebase

Action Items

• Developers install the Prettier extension in VSCode. Prettier-VSCode repo
  • Refer to the Readme to install Prettier.
  • Once installed, we'll discuss any bugs we come across on our local repo.
  • Fix any issues that come up.
  • Push a PROD ready branch to 311-data/main.
• Propose a code formatting standard. Consider providing...
  • .prettierrc
  • .editorconfig
  • examples of this formatting configuration on another repo
• Team demo, get feedback
• Push Prettier team standards config to 311-data/main branch.

Resources/Instructions

• Link to @efrenmarin45 Dev.to article on Prettier: https://dev.to/efrenmarin/format-your-code-using-prettier-like-a-pro-fj8

[efrenmarin45]

The article goes over setting up Prettier and automating the formatting process by using git hooks. The two files used to format in the example (.prettierrc, .editorconfig) uses the default formatting VSCode comes with out the box. I'd recommend trying out the workflow locally on a personal project to get the gist of how formatting works.

[ryanfchase]

This ticket is ready to be picked up 👍

[traycn]

Hey @ryanfchase

Let's move this ticket back to Icebox as the Action Items aren't clearly defined and would have to involve collaboration with the dev team. I propose we follow these steps as individual Dev issues for the Epic (#1877):

1. Update this ticket with action items to add Prettier to our application with a default formatting dev team agrees on.
2. Developers run Prettier's default formatting locally to:
   • address any bugs/issues we come across
   • share our thoughts for custom formatting we'd like to implement as a team
     • define the teams standard for code formatting
     • NOTE: Add docs OR reference prettier config for devs to know what the teams formatting standards are
3. Update Prettier with the teams standard on code formatting in the config.

---

Btw @efrenmarin45 I really appreicate your article on Prettier! I agree with running Prettier locally. In our next team meeting let's all discuss the intent behind formatting and talk next steps in using Prettier in our development workflow.

[ryanfchase]

@traycn works for me, but I think we should just incorporate your proposed list into the action items of this ticket. I don't see a point of splitting it into multiple tickets when one dev should be responsible for integrating the prettier config files.

If Steps 1-3 are integrated into this ticket, then we can remove my proposed ticket "Implement and test Prettier configuration files" and "Implement and test Prettier configuration files" from the Epic.

Do you have thoughts on when we should actually perform and commit a Prettier format for the entire codebase?

[ryanfchase]

Moved ticket to New Issue Approval since we are discussing Action Items.

[traycn]

Let's set this ticket for Post-Launch and start working on this implementation when we're more moved along with Pre-Launch.

Concerning the Epic for this Prettier implentation, what was the reasoning behind creating an Epic? Also how do PMs decide on when a task is an Epic or an individual issue?

[ryanfchase]

Let's set this ticket for Post-Launch and start working on this implementation when we're more moved along with Pre-Launch.

Concerning the Epic for this Prettier implentation, what was the reasoning behind creating an Epic? Also how do PMs decide on when a task is an Epic or an individual issue?

Per meeting -- I discussed some high level definitions:

• Issues: a basic task with a definitive end-goal or deliverable
• Epics: a grouping of Issues, not necessarily defined by Milestone (e.g. there may be pre-launch vs. post-launch tickets on our Testing Epic)
• Milestones: categories that can be assigned to Issues, used in determining ordering and prioritization of work on the 311-Data team.
  • Pre-Launch: colloquially refers to all milestones that come BEFORE the Launch milestone (e.g. 01 - 09)
  • Post-Launch: colloquially refers to all milestones that come AFTER the Launch milestone (e.g. 10.01 - 12, W - Z)

As for deciding between Epics / individual Issues, there isn't an explicit process for this. I'm usually open to discussion on when to create Epics. Epics tend to be mostly useful for Leads and PMs, we don't put much emphasis on organizing these for volunteers on the Individual Contributor level.

[ryanfchase]

I'm happy to prioritize this as post-launch, but we should update the Action Items based on our discussion. I believe we have everything we need to move this forward.

• Your proposed action items: DEV - Implement Prettier code formatting standard #1887 (comment)
• My revised action items: DEV - Implement Prettier code formatting standard #1887 (comment)

I can move forward with this when I have your sign-off.

[traycn]

Updated the Actions Items of this ticket with these steps:

1. Update this ticket with action items to add Prettier to our application with a default formatting dev team agrees on.
2. Developers run Prettier's default formatting locally to:
   • address any bugs/issues we come across
   • share our thoughts for custom formatting we'd like to implement as a team
     • define the teams standard for code formatting
     • NOTE: Add docs OR reference prettier config for devs to know what the teams formatting standards are
3. Update Prettier with the teams standard on code formatting in the config.

Also updated the Epic: Prettier Code Formatting 1877 Action Items.

I had changed the complexity of this task as there are a lot of moving parts with both development and team collaboration. These need more time since it's dependent on the teams feedback.

[ryanfchase]

after discussion, we are blocking this ticket until we have hit our Launch milestone. We don't want any devs to pick this up until after we have launched. Completing this ticket will require all devs to pause work on tickets until they have adopted Prettier. Dev lead expects to manage bugs that come up while devs are integrating Prettier