extensive-react-boilerplate VS secure-auth-no-local-storage

The efficiency of using ESLint rules during the development of your project is also manifested in writing custom rules. Since ESLint has extensive functionality and flexibility, you can create not only formatting and rules but also consider internal project decisions. For example, working with forms, it is possible to control and warn developers about possible unnecessary renders, incorrect solutions when working with objects, or simply point out unused imports. For example, extensive-react-boilerplate addresses such issues as follows:

How much time do we typically spend on project setup? We're talking about configuring installed libraries and writing boilerplate code to structure and implement best practices for achieving optimal website performance. At Brocoders, we often start new projects from scratch. That's why over 3 years ago, we created a NestJS boilerplate for the backend so that we wouldn't have to spend time developing core functionality that the end user doesn't see but is crucial for developers. Over this time, the boilerplate has received 1.9k stars on GitHub and has gained significant popularity beyond our company. Now, we've decided to take it a step further and created the Extensive React Boilerplate for the frontend. Its purpose is to keep our best practices in project development together, avoiding familiar pitfalls and reducing development time.