Streamline code formatting

[trumbitta]

Description

Why

• I'm about to start working on fixing the linting problems the dashboard app logs, but ESLint and Prettier have some common gray area and it's better to start with consistently formatted code to have an easier time in handling this common area
• Basically why Prettier exists: having an automated coding style which is readable, consistent, and not particularly prone to be argued upon: again, @loujaybee this improves DevX

What

• Adds Prettier support and configurations
• Format on save
• Batch format everything Prettier can format to obtain a good starting point
• Monorepo components / folders are batch-formatted in separate commits in case you prefer to accept this only for some of them

TODO

• Get feedback, is this useful? (I think it's fundamental!)
• Get feedback, do we want it everywhere Prettier can do its thing? (again, see the commits)
• Add notes to README (which ones depends on the answer to the question just above) about this
• Add a pre-commit hook, just in case. But this seems better done in a separate PR after / with ESLint because Prettier suggests doing it with https://github.com/okonet/lint-staged#configuration and lint-staged suggests stabilizing ESLint before configuring it
• Get someone to try it with a Jetbrains IDE

How to test

Use, build, test Gitpod to see if this broke something (it shouldn't have, since Prettier only reformats code)

[roboquat]

@trumbitta: Adding the "do-not-merge/release-note-label-needed" label because no release-note block was detected, please follow our release note process to remove it.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[roboquat]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please assign akosyakov, alextugarev, corneliusludmann, csweichel after the PR has been reviewed.
You can assign the PR to them by writing /assign @akosyakov @alextugarev @corneliusludmann @csweichel in a comment when ready.

No associated issue. Update pull-request body to add a reference to an issue, or get approval with /approve no-issue

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS
• components/common-go/OWNERS
• components/content-service/OWNERS
• components/content-service-api/OWNERS
• components/dashboard/OWNERS
• components/ee/agent-smith/OWNERS
• components/ee/db-sync/OWNERS
• components/ee/kedge/OWNERS
• components/ee/payment-endpoint/OWNERS
• components/ee/ws-scheduler/OWNERS
• components/gitpod-db/OWNERS
• components/gitpod-messagebus/OWNERS
• components/gitpod-protocol/OWNERS
• components/ide/OWNERS
• components/image-builder-api/OWNERS
• components/image-builder-bob/OWNERS
• components/image-builder-mk3/OWNERS
• components/licensor/OWNERS
• components/local-app/OWNERS
• components/local-app-api/OWNERS
• components/registry-facade/OWNERS
• components/server/OWNERS
• components/supervisor/OWNERS
• components/supervisor-api/OWNERS
• components/ws-daemon/OWNERS
• components/ws-daemon-api/OWNERS
• components/ws-manager/OWNERS
• components/ws-manager-api/OWNERS
• components/ws-manager-bridge/OWNERS
• components/ws-manager-bridge-api/OWNERS
• components/ws-proxy/OWNERS
• dev/loadgen/OWNERS
• installer/OWNERS
• operations/observability/mixins/meta/OWNERS
• operations/observability/mixins/workspace/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[Siddhant-K-code]

We Can add small automation too, that will run the prettier script ( to format whole code) before every commit. This way whole code will be formatted well.

[gtsiolis]

Thanks for giving this a go, @trumbitta! 💯

Files changed: 894

❓ question: Could we break this down into smaller pieces or steps to make it easier and faster to review? Breaking down changes per component, starting with the bare minimum linting rules, or leaving markdown files out of the scope of these changes could help. 💭

Cross-linking relevant issue in #3841.

[trumbitta]

Thanks for giving this a go, @trumbitta! 💯

Files changed: 894

❓ question: Could we break this down into smaller pieces or steps to make it easier and faster to review? Breaking down changes per component, starting with the bare minimum linting rules, or leaving markdown files out of the scope of these changes could help. 💭

Cross-linking relevant issue in #3841.

Hey @gtsiolis 👋 , these are just 💅🏻 code formatting changes.
The linting one I'll work on right after we sort this one out 💪 💪 💪

I already created one commit for each component, so that you can for example:

• decide to review one component at a time by looking at its commit
• tell me you want Prettier just for component X and component Y, and I'll easily delete all the other commits

Is this what you mean?

Re: markdown files. Personally I'd rather use Prettier for everything it supports and never spend another second of my life over code formatting, but if you prefer keeping markdown files out of the thing, I can add them to the ignored files! Just let me know 😃

[gtsiolis]

Thanks, @trumbitta! I'm all in for adding prettier[1] support but would recommend a) breaking things down into smaller pieces if possible and if it makes sense in the spirit of MVC (minimum viable change) as well as b) starting with a bare minimum setup since prettier can be quite opinionated by default.

Let me pass this to the folks in @gitpod-io/engineering-webapp to decide what's the best way forward here. 🏓

[trumbitta]

Another common approach when adopting Prettier is to just have a "configuration file + format on save" setup and let it propagate changes over time.
I did it like this in the past, but it bloats PRs for months and a few files get always left behind because maybe nobody opens them for a very long time.
These days I like the YOLO approach more because once it's done you have a single point of adoption in your git history and you can start enjoying the benefits right away.

[trumbitta]

Another common approach when adopting Prettier is to just have a "configuration file + format on save" setup and let it propagate changes over time.

@gtsiolis 👋 any news? 😊

[gtsiolis]

@trumbitta I still stand by #7757 (comment) but I'd like to defer this to the @gitpod-io/engineering-webapp team for any additional input or decide what's the best way forward here. I've also just pinged the team internally to resurface this.

[gtsiolis]

@trumbitta after a short discussion about this with the team:

Thanks again for opening this! I'm going to take a bias-for-action here and close this for now as this currently seems to add little to almost no value for our users and causes more distraction for the team instead of helping us push forward our product's vision and strategy[1].

Following the comment in #7757 (comment), if you still think some of the changes in this PR could be useful, I'd recommend 🅰️ starting with a bare minimum setup and breaking changes into smaller pieces to make reviewing easier and avoid constant file conflicts as well as 🅱️ consider opening an issue to discuss beforehand such changes, their impact, etc.

Please, do not let this discourage you from contributing to other areas of the product. Thanks again for all your contributions!