Enhance Linting Rules: Add Prettier, Stylelint, and Stricter ESLint Configurations

[pplancq]

Description

• Noticed that the current ESLint rules were quite light, so I propose to strengthen them to ensure better code quality.
• Added Prettier for consistent code formatting.
• Integrated Stylelint for CSS/SCSS linting.
• For efficiency, I used my own shared configurations (@pplancq), but if you prefer, I can manually add all the configuration files instead.

I was also considering setting up Husky, a tool that allows you to add Git hooks in order to enforce code linting at commit time. I would like to know your opinion on this subject to see if I can integrate it into the project.

Related issue(s)

N/A

[SebastienDegodez]

@lbroudoux the usage of the pplancq packages has been well received, based on the feedback I’ve received. This one offers the flexibility to customize as needed without any issues. The overall rules are appreciated, and even in the event of a shift in direction, they can still be adapted or reused easily (copy).

[SebastienDegodez]

About Husky, I use in dotnet implementation (dotnet husky) but it's the same.

[lbroudoux]

I like consistency and helping maintainability so it's a +1 here!

I have one additional feature request, though: could we also ensure that files containing code (TS, TSX or JS here) contain the regular copyright header?

The model we have for Java files is:

/*
 * Copyright The Microcks Authors.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *  http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

[pplancq]

Thanks for your feedback!
Yes, I did notice in a previous PR that you intended to include this header consistently across all code files.
That actually ties in with an idea I had: setting up a Git hook (using Husky, for instance) to automatically add this header to newly committed files. I’d be happy to submit a dedicated PR for that. The PR could also provide feedback on existing files in the React project to help ensure consistency.

[pplancq]

I've set up Husky to introduce Git hooks for better control during development:

• Commit message validation using commitlint
• Pre-commit checks with lint-staged, running ESLint, Stylelint, Prettier, and TypeScript on staged files

To make this work properly, I updated the package.json to a workspace configuration, allowing us to share dependencies across packages. For now, I've only included the React project in the workspace. I preferred not to modify the old frontend or server dependencies just yet.

Eventually, the server will also be integrated into the workspace.

You might also notice a volta key in the package.json files. This has no impact on the project—Volta is a Node version manager I use to easily switch Node versions between projects. I pinned Node 18 for the server, since I saw that the Dockerfile uses a nodejs-18-minimal image.

Lastly, I updated the installation instructions for the new frontend in the INSTALLATION.NEXT.md file.

I hope these changes are helpful and align with what you were expecting!

[lbroudoux]

This is globally OK for me but I'm concerned about integrating dependencies on @pplancq packages: not about the quality of your work but about license compatibility issues and real need of non main stream deps.

Could you provide more explanations on these whilst I check if the license is actually an issue?

[lbroudoux]

LGTM