[dev env] Define a standard formatting method for the codebase (mostly javascript).

[XiaochenCui]

puter currently has on format standard on js code, which causes some troubles for contributors:

• when a contributor format a js file, it causes hundreds of diffs and make the pr hard to review
• vscode "format modified lines" is a temporary workaround but only works for tiny commits. it failed when a commit involves changes to nest block (if/for/...)
• different format tools yield different code, which makes a standard is desired

here I propose some solutions:

• [short term] make a "format-only" commit when needed
• [middle term] define a standard style for the code format, it should be integrated easily with popular editor (vim/vscode/...)
• [long term] add lint to ci

[Yasir-Rafique]

@XiaochenCui Hi! 👋 I’d like to help address this by implementing the short/mid-term solutions:

• Add a code formatter (like Prettier) with a config for the repo
• Make a single “format-only” commit to clean up the codebase
• Document the formatting process for contributors

Do you have a preference for the formatter style (Prettier/StandardJS/ESLint, specific rules)?
Would you like me to open a draft PR for feedback as I go?

[KernelDeimos]

There is some additional information about this here

@Yasir-Rafique

Do you have a preference for the formatter style (Prettier/StandardJS/ESLint, specific rules)?

This is the problem and part of why we haven't done this yet is we do have a style guide for backend, and I haven't been able to configure a formatting tool to accept it. If you can, that's a big win.

I am convinced that we need to do this because most contributors will take it for granted that the auto-formatter in their editor understands our project, but we need to solve these problems:

1. when/how to merge formatting changes
2. we should get the backend styleguide to be supported if possible; there are good reasons for the choices in there
3. we need a process in place to eliminate resistance if somebody submits a PR with incorrect formatting; if they have to fix it manually they might just stop contributing

[Yasir-Rafique]

Hey Thanks for your detailed feedback and for explaining the concerns around mass formatting changes. That makes total sense, and I agree it’s definitely better to go step by step to avoid unnecessary merge conflicts. I’ve just updated my PR so that it now *only adds the Prettier config files *(.prettierrc and .prettierignore) with no formatting applied to the codebase yet, just as you suggested. I’m totally open to the choice of formatting tools! If Prettier on its own doesn’t quite cover everything in your backend style guide, I’d be happy to help figure out the right combination—whether that’s adding some ESLint rules, plugins, or tweaking settings. If you want, I can take a look at your style guide and see how close we can get with Prettier and/or ESLint, and make a note of any rules that aren’t supported out of the box. Here’s how I see the next steps: 1. Make sure the config matches what you’re aiming for—happy to update it if you spot anything. 2. Once everyone’s happy, we can plan out the actual formatting changes, maybe in stages, whenever it makes sense for the team. 3. I’m also happy to help put together a contributor guide or some quick docs for formatting, if that helps future PRs go smoothly. Let me know what you think, or if there’s anything else I can help with! I appreciate you taking the time to spell this out.

[KernelDeimos]

Thanks! There is a styleguide for backend here. We haven't written a styleguide fr the frontend code yet or other modules. One of the challenges is going to be figuring out how we can do this incrementally - if we can apply formatting changes only under specific directories, and increase the coverage over time, that would be perfect.

Will Prettier and ESLint work together, or is this a one-or-the-other type of situation where we need to weigh the pros and cons?

I'll merge your PR if/when we decide that we're including Prettier, but I'd like to hear your thoughts first. It looks like both have support for plugins, but if either can represent the styleguide with configuration alone that would be ideal.

[Yasir-Rafique]

Thanks. I have had a close look to the backend style guide and here’s what I think:

• Prettier can handle almost all the formatting rules outlined: 4-space indentation, trailing commas, line length, spacing, and brace style.

• ESLint (with a couple of plugins) can cover import ordering, enforce some naming conventions, and help with things like making sure JSDoc comments are present for backend services/methods.

• There are a few things that would still need to be handled by documentation or a custom script, like the copyright header and special variable/file naming conventions.

If it sounds good, I can put together a starter ESLint config and Prettier config based on your style guide and point out which rules are auto-enforced and which are still “manual.”
For incremental adoption, Prettier can be run just on the specific backend directory to start, and we can expand coverage over time as you suggested.

Once you approve the PR and advise on the above, we will be ready to start working on the next steps.

Thanks again for looping me into this process!

[KernelDeimos]

Thanks, I've merged your PR - your plan sounds good. I think the broadcast module would be a good first directory to move to auto-formatting because it's not to small to miss common cases but it's still pretty small.

[Yasir-Rafique]

Thanks for merging the PR and pointing me to the broadcast module. Sounds like a great place to start!

Based on our earlier plan, here’s what I’ll do next:

• Will set up an initial ESLint config and double-check our Prettier config for the broadcast module, using your backend style guide as the reference.

• Will run Prettier just on src/backend/src/modules/broadcast for incremental adoption, as we discussed.

• Will point out in the PR which rules are being auto-enforced and which (if any) still need manual/documentation review.

Once that’s done and you are happy with the result, we can gradually expand this process to other modules. Let me know if you want to review the ESLint config draft before I apply it, or if you have any preferences for plugins or specific rules.