ni / javascript-styleguide

JavaScript and TypeScript Style Guide
MIT License
9 stars 9 forks source link

Add Prettier configurations #96

Open mure opened 2 years ago

mure commented 2 years ago

https://prettier.io/

pakdev commented 10 months ago

I concur. Prettier improves consistency and lightens developer burden.

Edit: I don't care if the formatter we use is prettier or something else. It'd just be nice to have a tool automatically format my code

rajsite commented 10 months ago

Mentioned to @pakdev that you can use prettier-eslint (like Nimble does) with prettier so that the NI Eslint rules are followed but sounded like the goal was to get the NI JavaScript Styleguide to recommend that by default instead of per project / code base / team.

pakdev commented 10 months ago

According to the prettier-eslint project:

This formats your code via prettier, and then passes the result of that to eslint --fix. This way you can get the benefits of prettier's superior formatting capabilities, but also benefit from the configuration capabilities of eslint

So, this project isn't any different from manually configuring prettier to adhere to our eslint rules. I was able to accomplish that for Javascript with this simple config:

{
    "arrowParens": "avoid",
    "printWidth": <you choose>,
    "singleQuote": true,
    "tabWidth": 4,
    "trailingComma": "none",
    "overrides": [
        {
            "files": "**/*.yaml",
            "options": {
                "tabWidth": 2,
                "singleQuote": false
            }
        }
    ]
}

Note: It's possible there are other settings required that just haven't been exercised in the code I formatted. Because of that uncertainty, prettier-eslint is beneficial as it infers a prettier config from eslint's config. However, my point is prettier-eslint isn't somehow avoiding the "should we use prettier" debate (in part or in whole)

pakdev commented 10 months ago

NI JavaScript Styleguide to recommend that by default instead of per project / code base / team.

And maybe this recommendation would be too big of a pill for the NI Javascript Styleguide to swallow. The alternative is to at least allow its usage on a developer-by-developer basis. What do you think about the following guidance?

"Individual developers are allowed (and encouraged) to use code formatting tools as they see fit so long as their changes do not conflict with the established eslint rules of this guide. However, if their code formatter introduces changes outside of the code they're directly modifying, they must first submit the code formatter changes in a separate PR."

TrevorKarjanis commented 10 months ago

NI JavaScript Styleguide to recommend that by default instead of per project / code base / team.

And maybe this recommendation would be too big of a pill for the NI Javascript Styleguide to swallow. The alternative is to at least allow its usage on a developer-by-developer basis. What do you think about the following guidance?

"Individual developers are allowed (and encouraged) to use code formatting tools as they see fit so long as their changes do not conflict with the established eslint rules of this guide. However, if their code formatter introduces changes outside of the code they're directly modifying, they must first submit the code formatter changes in a separate PR."

This will just result in constant formatting changes when not all developers are using Prettier in a repository. Therefore, maybe should be repository by repository.

pakdev commented 10 months ago

This will just result in constant formatting changes when not all developers are using Prettier in a repository. Therefore, maybe should be repository by repository.

Maybe. I'd be curious to see if that's the case though and why - especially if this project provides prettier/\<code formatter> config(s). Perhaps we could fix these inconsistencies by activating more eslint rules (or making the formatter less opinionated, though that's my least favorite approach)