Thoughts on repo, codebase and project structure

[gantoine]

It's so cool to see how much this project has grown in just a few months! I have a couple thoughts on ways we could improve it

Move feature requests to Discussions

Discussions would allow the community to pitch ideas (features and beyond), debate their merits, vote on our favourites (which could help with prioritization), and respond with threads.

Enable Projects

While I find myself wanting to build some of the requested features, I sometimes worry that

1. they might not be wanted in romm
2. someone else is already working on them
3. my interpretation of the request is wrong

Projects would allow us to pre-select the features we want to add, categorize them, better define them (after discussing them), self-assign them, and (possibly) track their progress.

As for the features themselves, I have no opinions on things like firmware, DLC, save files, integrations, scrapers, etc. That much I leave to those who have been collecting ROMs for much longer then I.

Code structure

We as developers have a lot of opinions on architecture, linting, code style, etc. And as much as I'd like to just make sweeping changes to the codebase, to make it more internally consistent and bring it in line with community standards, I think we should have some conversations about the subject and narrow down the changes that would actually improve it.

• Auto-formatting and linting for Python (pylint, flake8, black, ruff) and JS (eslint, prettier, stylelint)
• Translating both Vue components and JS files to Typescript
• Validate endpoint logic with pytest

I find the current folder structure and backend/frontend split works fairly well, and I don't see any reason at the moment to make more sweeping changes to it.

[zurdi15]

First of all, thank you for your kind words and thank you for your effort making RomM a better software :)

Move feature requests to Discussions

Discussions would allow the community to pitch ideas (features and beyond), debate their merits, vote on our favourites (which could help with prioritization), and respond with threads.

While I agree with the fact that the discussions are a better place to make brain storming, discuss feature ideas and vote the most interesting ones, I don't know if that is going to be a good change for the users? And to link that with the Projects section should we as developers open the issues taking into account the discussions or how would you manage it?

Enable Projects

While I find myself wanting to build some of the requested features, I sometimes worry that

1. they might not be wanted in romm
2. someone else is already working on them
3. my interpretation of the request is wrong

Projects would allow us to pre-select the features we want to add, categorize them, better define them (after discussing them), self-assign them, and (possibly) track their progress.

As for the features themselves, I have no opinions on things like firmware, DLC, save files, integrations, scrapers, etc. That much I leave to those who have been collecting ROMs for much longer then I.

I totally agree, RomM is growing so much so I also think it is a good time to open Projects, and as I am not the only one developing this (you are helping me a lot since there is too much work) it is a better way to track the development and assign issues. Apart from that I can see here users have quite more knowledge about emulation world (I only use few emulators with basic config) so no opinion neither, I will listen to the community.

Code structure

We as developers have a lot of opinions on architecture, linting, code style, etc. And as much as I'd like to just make sweeping changes to the codebase, to make it more internally consistent and bring it in line with community standards, I think we should have some conversations about the subject and narrow down the changes that would actually improve it.

• Auto-formatting and linting for Python (pylint, flake8, black, ruff) and JS (eslint, prettier, stylelint)
• Translating both Vue components and JS files to Typescript
• Validate endpoint logic with pytest

I find the current folder structure and backend/frontend split works fairly well, and I don't see any reason at the moment to make more sweeping changes to it.

While I agree with that the current root structure is fine, RomM still need a lot of refactor in the frontend part mostly and in the ci/cd - testing part. I am learning frontend development with this project so I know there are a lot of things to do better aswel as in the backend part.

About the linting and unit testing, of course I also agree. I would take pylint + black for lint/format and pytest for unit testing.
Not sure about typescript because I don't know so much about typescript (the only thing I know it is somehow javascript with types) so no opinions in this point.

Branch naming convention

I think we should have a basic branch naming convention like: feature/xxxx, bug/xxxx, refactor/xxxx, etc

[gantoine]

I don't know if that is going to be a good change for the users? And to link that with the Projects section should we as developers open the issues taking into account the discussions or how would you manage it?

Another project I find does this well is homepage. While they're reached some level of feature-completeness and have stopped using Projects, the Discussions are still very active.

Not sure about typescript because I don't know so much about typescript

In the same way you're using type annotations in Python, TS allows for both faster writing (by explicitly defining the structure of your code) and safer refactoring (via implicit type checking) of JS code. The laaaarge collection of available types for third-party libraries also makes using those libraries easier and safer, as the type checker will complain if you mess up.

I think we should have a basic branch naming convention like: feature/xxxx, bug/xxxx, refactor/xxxx, etc

Since this would only affect collaborators I'm all for it. 👍🏼 Other contributors would still be free to use whatever branch names they'd like on their own forks.

I will listen to the community

Few are the maintainers who listed to the actual users of their projects, and fewer still who defer to their knowledge and experience. 🤝

[calebsmithdev]

Chiming in on the note of Typescript. If you decide to go this way, I'd be happy to help with adding some types and adding them where appropriate. Always happy to champion some Typescript growth in a project!

[gantoine]

Alright most of what was discussed here has been done, and a deeper dive into the codebase should happen in another context. Closing this discussion.