Enforce JS formatting standards to improve readability and encourage collaboration

[robyngit]

Describe the feature you'd like
Select a code formatting standard, and enforce it using a shared JS formatter tool / linter. Reformat all JS files in MetacatUI to align with this standard. Consider also implementing a pre-commit hook to prevent unstyled code from being committed.

Is your feature request related to a problem? Please describe.
Code in MetacatUI uses a combination of tabs and spaces for indenting, and has many other stylistic inconsistencies. The result is that the code tends to be difficult to read, understand, and update. I believe these challenges are a barrier to onboarding new developers and discourage contributions from external developers.

Additional context
Given that this will cause major merge conflicts for users who have extended MetacatUI, and that any code that doesn't follow the new standard will not be valid, this should be considered a breaking change. This was discussed as part of the the 3.0.0 release.

[robyngit]

There are plenty of formatters, linters, and standards to choose from. I haven't done a deep dive into what's available, but standardJS looks really nice. Here are some highlights:

• No config required: "At the end of the day you have to 'just pick something', and that's the whole philosophy of standard -- its a bunch of sensible 'just pick something' opinions."
• Supports extensions for Atom, VSCode, Vim, Emacs, Brackets & Webstorm
• Can use in pre-commit hooks
• Has an automatic formatter
• Widely used (27.9K stars on GitHub)

[robyngit]

We should also consider prettier. From @ianguerin:

I usually opt for prettier because it has very little configuration, it makes a lot of its own style decisions rather than letting me make them

[ianguerin]

Prettier also plays nicely with eslint with projects like eslint-config-prettier that ensure there are not conflicting rules with having both configured.

Eslint seems to be more extensible, it lets you define your own rules, so you can enforce things like property name ordering, or import ordering, the possibilities are great.
I was playing around with eslint's playground to try to restrict a specific property from Backbone.View declarations, and it even provides a shareable link!

[robyngit]

I've explored ways to minimize merge conflicts for projects that have extended MetacatUI. Here's the approach I tested:

Setup:

• Created a branch from develop simulating an extended MetacatUI project with various modifications (adding/removing methods, altering CSS, etc.).
• Created another branch from develop and configured it with the prettier setup, applying formatting to all files.

Test 1: Merging both branches

• Merged the prettier-formatted branch into the modified branch.
• Result: This resulted in confusing merge conflicts, making it challenging to discern changes from formatting differences.

Test 2: Applying prettier before merging

• On the modified branch, cherry-picked the prettier configuration commit.
• Ran prettier on all files and committed these changes.
• Merged the prettier-formatted branch into this now formatted modified branch.
• Result: This approach was much more effective. The merge conflicts showed actual changes rather than formatting differences.

This indicates that proactive formatting could mitigate the impact of such changes on extended versions of MetacatUI. Since merge conflicts are somewhat inevitable when integrating updates, the additional formatting conflicts should be manageable. We could guide users on pre-formatting their code before merging the latest updates. Additionally, we could consider releasing linting changes separately from other updates in order make it easier for users to format their code and resolve conflicts independently of features/bug fixes. Otherwise, we could provide the exact commit hash for the formatting config, enabling users to cherry-pick this commit and apply prettier themselves.

@vchendrix @helbashandy @yvanlebras - Given your experiences with extending MetacatUI, I’d love to hear your feedback on this approach!

[robyngit]

Released in 2.29.1