Repository Refactoring (proposal)

[erikyo]

In order to avoid making a huge PR with generic changes, I'm going to write a tracking issue here that lists the changes I would like to propose, in that way we will have a sort of changes tracking to isolate changes by 'type'.

This issue supersedes #80, which involved a series of structural changes too delicate to be made all at once.

• Add Typescript for type checking (but still with js files) #81 - This pr is used to add typescript as a dependency, use it to generate types and add type references inside files
• Move files from lib to src and index into src #85 - Move files from lib to src (including index.js)
• Update deprecated substr and slice methods to their modern equivalents #84 - Remove deprecations (slice, substr)
• Fixes missing replacements for deprecated code #90 - removes deprecations
• Removes safe-buffer (not needed anymore) #87 - Remove the safe-buffer library, it's a fallback for node <5.0, but since we are requiring node >16 it's pretty useless
• speed up lexer parsing #88 - Speed up parser replacing regex with string comparison when possible
• fix missing types and jsDocs #89 - Enhances the jsDocs
• Track coverage using C8 #96 - Coverage report
• Tests for big endian mo files #97 feat: add support for compiling big-endian .mo files #98 - Full tests coverage
• Update docs #83 - Update changelog, version and readme (require should be replaced with import)

[smhg]

Thank you! I think you are overdoing it a bit for the smaller changes :) But your effort is great!
Let's start with 2) and 3) I guess?. If you keep the PR's focussed on a clear set of changes, I can merge quickly.

[erikyo]

yep that the reason why i decided to breakdown the previous issue into multiple tasks, this way the pr will be much less loaded and consequently quicker to verify

if you kindly create a development branch, I make my pull request target that branch and we can work there without modifying the master (at least until all or part of these modifications are completed).

what do you think? Unfortunately, some modifications, especially those that require files to be moved, would lead to merge conflicts and some tasks (such as task 2) require that previous pr's have already been merged.

ps all these changes have already been made in a fork I just need to cherrypick changes. ps all these changes have already been made in a fork, I just have to choose the changes. Actually I would have more, for example the parsing process could be speeded up by about 20% (tested)

[smhg]

@erikyo would you be ok to join this project as a maintainer?
I don't have enough time currently to follow up on your (very much appreciated) efforts. They seem well thought out and it would only make sense you can take care of this yourself if you ask me.
Please let me know and I will add you here on GitHub.

[erikyo]

Yes i can't hide that I would be very pleased but at the same time I am aware that this is a very heavily used repository and i will still need a second eye to approve any changes to the master. If it's ok for you, it would be really cool for me. Thanks!

[johnhooks]

@erikyo I would help support you with code review and feedback.

[erikyo]

That would be great! Your experience is certainly a great help 🚀

ATM I'm moving the pull requests to the development branch, so they can be merged without touching the master for the time being.

[johnhooks]

@erikyo I have a little more context now reading this issue.

It seems where the breakdown between this issue and PR #86, plus my comment #86 (comment)

If the goal is to use the development branch as a staging for larger changes to master, everything that is merged into development has to go through CR and be approved by the maintainer. Otherwise, the PRs for development -> master have too many unrelated changes.

[erikyo]

Consider this branch as a pre-publication quality control checkpoint. I've included you in this process so that you have the "last word" over it.

My intention was to utilize that specific branch within the 'Release Branching Strategy.' However, to avoid inconveniencing the maintainer (who generously provided me with the opportunity), I independently handled the pull request aggregation on this branch. I assigned him the task of overseeing the development pull requests, allowing him to review each one separately and maintain control over the final outcome before merging it with the master branch.

[erikyo]

@smhg we are close to having completed the set of improvements, what do you think? All that is missing at the moment are the tests (to achieve 100% coverage) and to update the readme. Consider that doing the tests is also intrinsically revising the pr and unless problems arise we can merge (without regret) the new changes.

[smhg]

@erikyo can you please tell me what to look at? I've received so many notifications over the last few days I couldn't possibly read them all (I'll look for a way to disable those).

[erikyo]

The most important changes were made here:

#89

That pr many lines have been changed but on the other hand nothing of the functional code level have been touched as the most of the changes were related to the jsDocs (which at the end is a comment)