Standardize Our Prettier Automatic Code Editing

[jbubar]

Overview

In the dev meeting @trtincher and @martham0 noticed that our code extensions were changing the code in our pull requests unintentionally. We need to come up with a solution to standardize this.

Action Items

• Come up with a solution
• get bonnies approval
• finish writing out issue

Resources/Instructions

Possible solutions

• github actions
• CI tools (travis ci or jenkins)
• addition to readme
• .prettierrc file

[pawan92]

This will be looked at further in break out rooms.

[jbubar]

@drubgrubby and I are going to meet this week to go over this issue

[martham0]

Good source from @dmcneary https://mskelton.medium.com/auto-formatting-code-using-prettier-and-github-actions-ed458f58b7df

[akibrhast]

@drubgrubby @ahdithebomb @martham0 @dmcneary @hackforla/owners @ExperimentsInHonesty @pawan92

This is a demo repo with GitHub action configured to run prettier on all pull request.

I believe you can check it out in action by creating a pull request with weirdly formatted js,md and json files .
Before we add the new GitHub action to run prettier on pull request we should first run prettier on master and apply all the necessary changes

Blockers

• Needs approval

Resources/Instructions

Create a GitHub action with the code snippet below

name: Format
on:
  pull_request:
    branches: [master]
jobs:
  format:
    runs-on: ubuntu-latest

    steps:

    - name: Checkout
      uses: actions/checkout@v2
      with:
        ref: ${{ github.head_ref }}

    - name: Prettify code
      uses: creyD/prettier_action@v3.1
      with:
        # This part is also where you can pass other options, for example:
        prettier_options: --write **/*.{js,md,json}

    - name: Commit changes
      uses: stefanzweifel/git-auto-commit-action@v4.1.2
      with:
        commit_message: Apply formatting changes
        branch: ${{ github.head_ref }}

[akibrhast]

Output of running prettier on master as it is.

[drubgrubby]

@cnk - We are looking at implementing something to clean up and standardize code being submitted. We have started down a path using Prettier, which seems promising and @akibrhast has done some great testing and research.

In your advisory capacity, can you suggest how best to proceed in implementing something like this? It seems like it could be a great benefit, but I can see how it might cause some problems if not implemented carefully. Being the careful one, I want to make sure we're doing our due diligence.

Do you have any thoughts on this? Thanks.

[cnk]

I have some serious reservations about automating changes to our html/md files because they contain a mix of html, javascript, and Liquid template tags. We have already released a couple of bugs because someone's code editor "fixed" some things it did not understand.

Do you have a link to anything showing that prettier understands Liquid?

Something like https://prettier.io/docs/en/precommit.html would be a bit safer - but then everyone would have to have node installed to work on the project.

[drubgrubby]

@akibrhast - (From cynthia) "Do you have a link to anything showing that prettier understands Liquid?"

[akibrhast]

@cnk @drubgrubby
According to this, it seems that it Shouuuuld be fine ... 😅 😅 😅 😅
https://prettier.io/blog/2018/05/27/1.13.0.html#preserve-liquid-tag-contents-4484-by-duailibe

[drubgrubby]

@ExperimentsInHonesty - Not sure what the next step in decision making on this is. Should we put in questions and discuss on Sunday?

[kevinreber]

I don't remember if anyone mentioned this, but I found another option that I thought may be easier and give us more control. We can make our own ".prettierrc" file and configure the formatting so everyone has the same prettier conventions.

• https://prettier.io/docs/en/configuration.html
  If you're in VSCode, the only change you'd have to do is check off the "Prettier: Require Config" box in your settings.
  

[dmcneary]

As @cnk mentioned, using Prettier locally would be an option but would force each dev to use Node, as the package is installed with npm. The advantage to running the formatter as a Github Action would be that the dependencies for the website as a project stay close to where they are now.

If anyone feels up to investigating more, I would suggest running a forked repo of the website through the Prettier GH Action, then seeing what/if anything breaks. I'm pretty sure that it can handle Markdown files and Liquid in HTML by now, though those formats were unsupported before.

[cnk]

Great research! I think the way forward is:

• Decide our coding standards and create a .prettierrc file for the project
• Update our wiki saying we use prettier with links to how to run prettier locally before you submit a PR
• Run prettier and make one large pull request fixing all the existing issues
• Create a github action that runs on each PR that checks if running prettier in CI makes any changes - and fails if there are changes

[ExperimentsInHonesty]

I would add to what CNK said above that we should add something to our readme (which will soon be the contributing file) about installing the prettier extension on your ide to catch formatting errors before you submit your pr.

Isn't there a github install for a CI that uses prettier?

[cnk]

We might also like to look into ignoring our giant cleanup commit when we do git blame https://www.moxio.com/blog/43/ignoring-bulk-change-commits-with-git-blame

[jbubar]

Does anyone have any progress on this? Maybe we should discuss this in the next meeting

[akibrhast]

These is an image from a recent pull request I looked at. You will notice the diff is just the ide auto formatting spaces.

IDE auto formatting spaces

I believe a possible solution to this would be add a .vscode/settings.json file[ Given that most people are using vs code as their ide] to the root of this project with the following settings override.

// The default end of line character.
//  - \n: LF
//  - \r\n: CRLF
//  - auto: Uses operating system specific end of line character.
"files.eol": "\n"

// Format a file on save. A formatter must be available, the file must not be saved after delay, and the 
// editor must not be shutting down.
"editor.formatOnSave": false,