Add linting and formatting

[yevdyko]

This MR adds linting and formatting to simplify the maintenance of the library component.

What was changed?

• Add Prettier and its config for formatting.
• Format component using Prettier.
• Add pre-commit git hook that formats staged files.
• Add ESLint packages for typescript as a linter.
• Add ESLint config.
• Add React specific linting rules for ESLint.
• Add packages to integrate ESLint with Prettier rules.
• Add CI Github action workflow.
• Add documentation about ESLint and Prettier configurations.
• Format the whole project using prettier.
• Remove unused styles.
• Fix linting for example js files.

[jamesrweb]

@yevdyko Looks good to me, some minor documentation additions and workflow updates to change but otherwise a really nice PR so far!

[jamesrweb]

@yevdyko Can you test my changes please?

I updated the CI and removed the git hooks because the CI is where we should be automating the integration of new code. Please check that I removed all non-necessary dependencies and that the CI workflow makes sense. On a sidenote, you mentioned extra commits, this would only happen if changes occur, not otherwise and so if linting and formatting don't change something, nothing is commited. The CI just helps the developer to develop and the CI to integrate so that the developer doesn't need to worry about code verification, formatting or stylistic issues and can write code how they wish and we format it to our needs, so long as it is reviewed / tested then it makes life easier for everyone in my experience plus it is what CI is for anyway.

Happy to answer any open questions and really happy with your work, this is really good stuff my friend! 👍🏻

New review completed.

[yevdyko]

@jamesrweb I don't mind having a formatting step in the CI, it's more a matter of taste :) Also, if it's inconvenient, we can always change the approach we take.

After you specified the master branch as a trigger for the push in the CI I can't test how it works together :)

Please add also changes in the package-lock.json file. Committed the updated lock file.

Thanks for the feedback and support!

[jamesrweb]

@jamesrweb I don't mind having a formatting step in the CI, it's more a matter of taste :) Also, if it's inconvenient, we can always change the approach we take.

After you specified the master branch as a trigger for the push in the CI I can't test how it works together :)

Please add also changes in the package-lock.json file. Committed the updated lock file.

Thanks for the feedback and support!

I don't know why it does that and I cannot update the settings but the reason master is defined is because we only want the CI script to run for PR's into master or (if admin rights exist) pushed into master occur. If we had it run on PR A going into PR B which is targeted at master then in this case only PR B would run CI since A wouldn't directly need to since it wouldn't affect the main codebase. Does that make more sense? I amn't an expert so to say with GitHub actions so maybe I am missing something but I have found this flow useful in other personal projects but open to changes if we find a better way.

[jamesrweb]

Only one thing left and then LGTM!

[yevdyko]

I don't know why it does that and I cannot update the settings but the reason master is defined is because we only want the CI script to run for PR's into master or (if admin rights exist) pushed into master occur. If we had it run on PR A going into PR B which is targeted at master then in this case only PR B would run CI since A wouldn't directly need to since it wouldn't affect the main codebase. Does that make more sense? I amn't an expert so to say with GitHub actions so maybe I am missing something but I have found this flow useful in other personal projects but open to changes if we find a better way.

Yes, I don't mind, and let's stick to this flow. Thanks for adding a step with cache npm packages! 🤖