Format files

[amirhhashemi]

• I have read the Contribution guide
• This PR references an issue (except for typos, broken links, or other minor problems)

Description(required)

There are many unformatted files in this repository. I often encounter these when I'm editing a file, and my editor automatically formats the file on save. This can lead to numerous unintended changes, as those files were not formatted beforehand. As a result, I usually have to manually revert these changes to keep the PR clean.

To fix it, first I ran pnpm prettier --write . to format all files (a2e1a39). Then I fixed a few errors manually (92cc86c)

To prevent unformatted files from being merged, it's also essential to format them in the CI. I can implement this if you’re interested.

#999 fixes the Eslint error.

[stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[netlify]

✅ Deploy Preview for solid-docs ready!

Name	Link
🔨 Latest commit	3c790e3
🔍 Latest deploy log	https://app.netlify.com/sites/solid-docs/deploys/6776c3e70d5b8a0008c64416
😎 Deploy Preview	https://deploy-preview-998--solid-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[LadyBluenotes]

Thanks for taking this on @amirhhashemi. I think i'm going to close this issue and have someone from the docs team tackle it.

Do you mind making an issue for this, instead?

[amirhhashemi]

Thanks for taking this on @amirhhashemi. I think i'm going to close this issue and have someone from the docs team tackle it.

Do you mind making an issue for this, instead?

But why? It's just Prettier. Ready for review.

[LadyBluenotes]

Anything that impacts configuration should be handled by the team unless they are small fixes. It might be worthwhile reviewing the Contribution Guide as we go over how we like to approach issues and PRs.

For one, there are aspects of the docs that can be affected by these types of changes. I would rather have team members who are familiar with the site infra itself address them vs contributors to avoid it breaking parts of it. Since this would effect thousands of lines, I'd feel more comfortable having a team member address it.

We greatly appreciate each and every one of our contributors and the work they put into PRs, but we do need to follow the procedures outlined in the Contribution Guide. This includes having issues filed and approved prior to having a PR, to start, just to make sure it aligns with our goals for the project and doesn't break anything in the process.