- Follow the git flow model (https://nvie.com/posts/a-successful-git-branching-model/)
- Add changelog for each release and update package json.
- Before every release, audit npm packages for checking security vulnerabilities.
- (opinionated) Follow conventional commits (https://www.conventionalcommits.org/en/v1.0.0/) which automates generation of changelog (https://www.npmjs.com/package/conventional-changelog-cli) and helps the pr to be restricted to a particular task ( feature, bugfix, refactor, breaking change etc. )
I have suggested some comments but the mr is pretty big.
In general, it is better to not make a mr above a certain number of changes (+500-600), so that it is easy for the reviewer to go through the code and examine the quality of the code. Also, it makes the mr atomic, every merge request should only solve a single problem like a function has a specific task, so that we know the purpose of the mr. This has another advantage that we are not hesitant in merging the pr because it can introduce breaking changes.
In your case, the idea of the mr is very general and therefore could have been broken down to Conversion of react components to hooks (which in itself could be broken down into 3-4 mrs), removing redundant code (which could also be said to be refactoring) and removing memory leaks.
Probably too much of an information, so try to slowly think in this way or take up any other way in which code is manageable.
also watched the linked video https://www.youtube.com/watch?v=NpKVA5hL3pM
